The existing `KeywordIdents` lint blindly scans the token stream for a
macro or macro definition. It does not attempt to parse the input,
which means it cannot distinguish between occurrences of `dyn` that
are truly instances of it as an identifier (e.g. `let dyn = 3;`)
versus occurrences that follow its usage as a contextual keyword (e.g.
the type `Box<dyn Trait>`).

In an ideal world the lint would parse the token stream in order to
distinguish such occurrences; but in general we cannot do this,
because a macro_rules definition does not specify what parsing
contexts the macro being defined is allowed to be used within.

So rather than put a lot of work into attempting to come up with a
more precise but still incomplete solution, I am just taking the short
cut of not linting any instance of `dyn` under a macro. This prevents
`rustfix` from injecting bugs into legal 2015 edition code.

…ed as keyword in test.

Back-story: After reflection this morning, I realized that the
previous form of this test would allow the macro invocation to treat
the `dyn` input as a raw-identifier rather than a keyword, and since
the input was discarded by that version of the macro, the test would
pass despite the detail that the input `dyn` should not have been
parsed as a raw-identifier.

This revision fixes that oversight, by actually *using* the macro
input to construct a `Box<dyn Trait>` type.

Review feedback asked for the test to be generalized to include macros
2.0; that generalization is dyn-2015-idents-in-decl-macros-unlinted.rs

As a drive-by, I also decided to revise the test to make it clear
*why* we cannot generally lint these cases. (I already had similar
demonstrations in dyn-2015-edition-keyword-ident-lint.rs, but it does
not hurt to try to emphasize matters.)

I also added some commentary on the cases where we could choose to
make the lint smarter, namely the situations where a macro is
*definitely* using `dyn` as an identifier (because it is using it as a
path component).