Add support for reasoning about server semantic version

Note: Currently, this is just for the chunkedgraph, but could easily be extended to the other services if we like the pattern

This PR adds

Adds logic for talking to an endpoint which just returns the full semver for the service
- Happens on sub-client creation
Stores this info as a Version object, which allows for easy operations like checking >,>= etc.
Adds a decorator for convenience, which allows specification that a method or its keyword arguments are only valid for specific constraints of server version
- Opted not to do that for arguments, could discuss further but since those are required that felt like it didn't fit the pattern
As an example, applies this decorator to a recent addition to the level2_chunk_graph bounds argument

A few things we discussed but I think are separate PRs

In theory, this kind of reasoning about the server version might allow for consolidating the multiple API version clients into one for each service, with method-level logic about dispatching to particular sub-functions depending on the version
There are some use cases that don't fall under the decorator that are more adhoc, for instance, the recent bug where using timestamp and select columns can be unsafe. I think those will need to be done on a case by case basis, but could at least use some of the tools here

[ ] How to generalize testing with this kind of thing (since mocking needs to happen @ client level)
[ ] How to handle case for servers that don't have this endpoint yet (I have some ideas here but it gets ugly)
- [ ] How to refactor to use handle_response but be OK with a 404 error