Minor fixes to $crate behavior

[Daniel-Aaron-Bloom]

The description of the behavior of passing $crate to a proc-macro is missing, this PR adds one.

Similarly the behavior of ident matching $crate isn't captured. Every other fragment specifier which matches $crate goes through PathIdentSegment which does contain $crate, but neither IDENTIFIER_OR_KEYWORD nor RAW_IDENTIFIER can (or should) match against $crate. Introducing a new definition just to capture this behavior seems like overkill, especially since it would only be used once, so adding an inline or-clause seems like the cleanest solution.

[joshtriplett]

This looks correct to me.

[ehuss]

Thanks!

I noticed there were quite a few changes to $crate behavior in rust-lang/rust#37213 in 1.14.

I'm slightly uneasy with this because I don't know what is going to happen in the future with RFC 3243 where a crate may end up being a path (foo::bar). I suppose since it will be opaque it's probably not a big deal, but still feels a little weird.

I'm not super happy with how $crate is defined, because it is a bit scattered (in paths.md, macro.decl.meta.dollar-crate, and macro.decl.hygiene.crate). For example, a naive reading could make one think that they could pass $crate into an ident from outside a macro definition, but that is not the case. Only the text in paths.md makes that really clear that it can only be passed in from a transcriber. Anyway, maybe for another day.