Propagate procedure attributes from AST to MastForest

[bobbinth]

With #1510 we have added procedure annotations to the assembler. These now get parsed and added to the AST. The next step is to process them and propagate the relevant attributes to the MastForest. But there are a few open questions around how this information should be handled that I think we'll want to pin down:

• The whole "can we support annotating re-exported procedures" question. I think an easy "yes" can be given for some annotations. For example, if we add support for lints/deprecations, and wanted to mark a re-export as @deprecated("0.2.0", "use bar instead"), that's fine, as the re-export being deprecated when the original definition is not has value; similarly, they could both be marked deprecated differently, and resolving that conflict is obvious, as the one closest to the call site takes precedence. It's a completely different situation for annotations that aren't just "soft" metadata though, and may imply something about the behavior of the callee, or worse, change the behavior of either the callee or the caller. Propagating attributes in such a way that we can "do the right thing" at a call site for a given procedure can be a non-trivial question, if every re-export can potentially add new annotations that may override/conflict with those of the actual definition. We don't necessarily need to answer these questions now, but the answer will affect how we propagate this information in the assembler.
• We probably should reserve some annotations that we're likely to need, and raise diagnostics if they are used (until we actually implement handling for them). For example, I'd probably reserve right out of the gate: warn, allow, forbid, deprecated, error, warning, test, derive, inline, type, doc, storage, feature, cfg, global, const, constant, dynamic, and whatever else is vaguely keyword like, or that we already anticipate using in the future or think we might want to use in the future.
• We might want to flag the annotations we need with the highest priority, ideally with different categories of semantics, and look at how we'd support those, and use that process to make sure whatever implementation we come up with for propagating annotation information is solid enough to support all of them without too many contortions.

Originally posted by @bitwalker in #1434 (comment)