Best practice: include a PDF of the project proposal with the creation review ballot

When we initiate a creation review for a new open source project or specification project, we lock down the proposal document from changes. More specifically, we prevent anybody other than the EMO and system administrators from changing the proposal while it is under creation review and after the project has been created (that is, the proposal cannot be changed after the community review period has concluded). It is, at least most likely, the case that that the proposal should not change during the specification committee ballot.

Over a long enough timescale, however, there is at least some chance that a proposal may change, or that some future update to the PMI might neglect to prevent changes after the community review period has expired. It may also be the case that some members of the specification committee are unsure of what specifically they are balloting on, or whether or not the document that they're balloting on is stable.

As a best practice, we should recommend that a read-only copy (e.g., PDF) of the proposal be attached to emails sent to the specification committee to initiate a ballot.

Related, we may consider adding an extension to the PMI to output a "clean" PDF. Or, maybe we can just work on the CSS to make the existing print output cleaner.

/cc @mplagge @mdelgado624