Remove 'same crate proc macro' drawback and replace it with discussion under reference explanation, since it's an issue that isn't introduced by this RFC and will also probably share a solution.

Remove anything about attribute expansion order, since that's not settled yet especially w.r.t. `#[cfg]`.

Remove anything in the reference section about hygiene, since that's not a focus for the macros 1.2 stabilisation push. Add a quick discussion about being forward-compatible with future hygiene work.

Expand discussion on how to keep this API forward-compatible with various issues.

- Fix up examples
- Include a (currently badly verbose) full expansion example.
- Clarify the input and output token formats.
- Add some related unanswered questions.
- Include some bikeshedding TODOs.

By focusing less on the proc_macro API, and caring more about how a
library using it would work, we greatly simplify the usage.

Moving to 'only mark a part of the call tokens' removes the need for a
fully-fleged API: once we know how tokens and their properties work we
can hijack that.

New name is goal-oriented enough that I shouldn't need to change it
again.

Remove details on tagged tokens proposal, add brief overview of tagged
tokens and proc macro function proposals, sneak in the macro callbacks
proposal.

Clean up line width and examples.

Pivot to eRFC.

…er-macro-expansion.md

This is the start of a total rewrite of the RFC, other than (most of)
the motivation section. The new version should actually follow the RFC
template, as well as having better structure following comments from
@pnkfelix.

Adds justifications for main design choices - making expansion
asynchronous, accepting arbitary token input, and using the builder
pattern.

misc fixups, flesh out builder pattern

Add attribute macro corner cases

update motivation to highlight the two bits that are relevant

Add section on deadloc

Thanks @chris-morgan!

Co-Authored-By: Chris Morgan <me@chrismorgan.info>