Create a plan for persistent storage upgrades

Upgrading postgresql releases over an existing installation has been painful for years due to:
- machine-specific representations stored on disk (big-/little-endian, floating point)
- the inability for new postgresql releases to read the older formats
- extension upgrades

These pain points are somewhat alleviated by pg_upgrade since rewriting the entire database is often untenable for ever-increasingly large data sets.

To ensure that Project:M36 doesn't hit this same hurdle, we should plan on making upgrades to binary releases as smooth as possible.

Considerations:
- minimize downtime
- minimize steps (automate away upgrade process)
- don't rewrite the database by default
- do allow the user to choose to rewrite the database in case the user wishes to continue to use the older release (pg_upgrade's hard link or copy dichotomy)
- live, in-place upgrades (?)