Consider allowing libraries to downgrade version, too

[jkomoros]

61 allowed libraries in an old format to be seamlessly upgraded. This allows new client to talk to old hosts. Typically (at least for now) hosts are less likely to be updated (that's the nature of a federated approach), and the client is likely to be up-to-date.

But in the future where there are clients running in a hosted location independent of their own host, it might be possible for there to be a host ahead of a client. In those cases, it would be nice if Library.query() could return a 'downgraded' Library in an old format.

The way to do this would be to add a downgrade_library_data in polymath/upgrade.py, one for each version. It would be the inverse of the upgrader script for each version.

[jkomoros]

This will be harder than I originally thought, because we don't (currently) bump the version number for backwards-compatible changes. (For example if we fixed #31 we'd probably leave the version number the same). This means that the downgrade flow would have to downgrade the format to the shape it was at the very beginning of that version number, not with any extra additions. That's not impossible but it will be harder to keep track of; as new extra optional features are added on a version number, you'd have to go back and continually extend the downgrade script to undo those changes if it finds them, too.

This machinery would get significantly easier to administer if we had #59