PEP 458: add hash algorithm transition plan

[lukpueh]

Context:
Addresses a review comment from @dstufft on #1203 (comment), and follows a discussion in secure-systems-lab#68, where @brainwane proposed more detailed workflows. My reasoning for keeping it brief was that I was under the impression that client and uploader workflows are not actually in the scope of PEP 458. If desired I am happy to add additional details.

Changes:
Add subsection to section "Managing Future Changes to the Update Process" that explains how to transition from an old (e.g. because it has become weak) to a new (e.g. stronger) hashing algorithm without disrupting client workflows.

[brainwane]

@mnm678 heads-up; how should this PR be dealt with? Perhaps you want to address it in the Discourse thread?

[brainwane]

@ncoghlan @dstufft Would welcome your thoughts on how to proceed here. Perhaps @mnm678 should sort of introduce it and talk about it in the Discourse thread?

[ncoghlan]

I think it's in scope here, since the main requirement is to show that migrating away from a compromised hashing scheme is at least possible, even if it wouldn't be quick.

(The right BigQuery queries would even allow for data driven decisions on when it was reasonable to stop publishing the weaker hashes)

[lukpueh]

Thanks for reviewing and merging, @ncoghlan!