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.

I don't like having methods on params types. They should just be "structure over the wire".
I also prefer APIs that return a list of things, rather than returning a map over the wire.
I believe we *could* return a map, since JSON supports that sort of thing (as long as all the keys are strings, at least). But IMO a list of key,value is the same as a "map" of key,value over the wire, and it should be up to the caller to supply the structure, and not a property of the API definition.