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.

Looking at this code makes me wonder if returning a map for facade-name-to-versions will be more useful. If we need to do lookups by name like that frequently, it definitely makes sense. Another option is to have something like type FacadesVersions []FacadeVersions in params, and define methods on it like Versions(name string) []int. Thoughts?