Admin.Login() describes all known Facade Versions

This updates the API so that "Admin", "Login" now describes what Facade Versions are available.
Note that ideally, this would be a new version of Admin Login (v1). I have not gotten the Client to pass in versions != 0, though, so I didn't go that far yet. (It will require changing the type of root that Admin is, as well, since only custom FindMethod ones are able to have multi-version support.)

This should be a relatively straightforward change. It updates Login so that it reports back the known versions of all Facades, and updates state/api.State so that it tracks AllFacadeVersions.
I have the stub of BestFacadeVersion written out, but I haven't implemented it yet, because we need to track what versions of the facades the client code is expecting to work with. (I can just remove that if we don't want to think about it yet.)

For context, the overall API versioning spec is available here: https://docs.google.com/a/canonical.com/document/d/1fPOSUu7Dc_23pil1HGNTSpdFRhkMHGxe4o6jBghZZ1A/edit?usp=sharing
(that document should eventually be rolled into a api-versioning.md file in our source tree, but it was iterated on there so that we could have comments, and finalize the spec.)

Note that the API returns the facades as a list, and we transform that list into a map for the client. We *could* just return it as some sort of map, but it seemed more appropriate (to me) to return a list in the API.

The API returns sorted results (or it should). However, BestFacadeVersion is going to assume the data is sorted, so with a "lets not assume but enforce our assertions" I sort it again. I can improve the comment if you want.