Add context to "may be out of date" sections

[workingjubilee]

Many places in the guide mention "this section may be out of date", such as in the parser. This is unfortunately quite ambiguous because the writer usually has not contextualized it with a "when" or "why", and so the reader does not know how much to trust or mistrust the information. Such comments should be marked with enough data to provide a reasonable amount of context, possibly including but not limited to

0. a reason for why the data may be out of date other than "change"... change is a constant across the project
1. a time the comment was added (visible in git blame but not on the website)
2. a link to a relevant WG, tracking issue, or similar, that may provide further explanation for the change process

[workingjubilee]

It's probably worth lifting this caveat from the "high-level overview of the compiler" into "About this guide": https://rustc-dev-guide.rust-lang.org/overview.html#constant-change

That way we clearly assert the base case of change initially.
Places we can update that assert the contents are possibly dated or that themselves might need an update due to time passing:

• Parallel Rustc
• Lexing and Parsing
• Helpful Links
• Backend Agnostic Codegen

This is a good example to reference: Specialization - Additional Resources. Something might have been dated, and is out of the guide's bounds, so it is unlikely to update, but it is given a time it dates to in the guide, so the reader can choose whether or not to click at all.

[igaray]

@rustbot claim