Don't accidentally parse MatchNt

[kmcallister]

This bit of macro from libcore:

( $($name:ident)+) => (
    #[stable(feature = "rust1", since = "1.0.0")]
    impl<$($name: Hash),*> Hash for ($($name,)*) {

was apparently parsing as a MatchNt $name:Hash, which breaks with my fix to #21370.

There's no need to parse MatchNt on a macro RHS, but we don't know we're on a macro RHS when we're parsing a token tree. Probably we should get rid of MatchNt. It's a weird "composite token" and the tokenizer phase is clearly too early to spot it. Rather we can look for the colon and fragment specifier when we parse a LHS TT into matchers.

Nominating 1.0-beta, P-backcompat-lang.

[kmcallister]

I guess it used to turn into a SubstNt in TokenTree::get_tt but that's too late on my branch.

[pnkfelix]

1.0-beta, P-backcompat-lang.

[kmcallister]

My best plan at the moment is to change the parser so it never parses MatchNts, and then do a separate pass to create them from SubstNt Colon Ident just before parsing a macro_rules! LHS. It's a hack for sure. Really, we should have a separate matcher-side token tree type, or some higher level AST for matchers. But I don't want to make huge changes all over macro parsing and transcription.

(There is already some other code that decomposes a MatchNt into SubstNt Colon Ident under some circumstances.)

[kmcallister]

The main parser won't even parse SubstNt at the moment, which is a known weirdness. Maybe that should be fixed along with this issue.