Allow clients to specify lower bound on protocol version

Motivating example: suppose we add a new constructor `LocalStateQuery` protocol. The question is: should this give rise to a new `NodeToClient` version? When we previously discussed this (starting at the end of https://github.com/input-output-hk/ouroboros-network/issues/2309#issuecomment-653392881, and continuing below), we concluded that there would not be too much point, since client code cannot actually take advantage of this new version. However, if client code can _tell_ the network layer, I want at least version such-and-such, then incrementing the version makes perfect sense, and now the client can say "I need version `x`, because I need query `A`".

For tooling such as the CLI, the version required would then depend on which query it needs to submit, which depends on the command given by the user. Again, allowing the CLI to specify a minimum bound here, and have this be included in the version negotiation, makes a lot of sense: the CLI would then be able to report to a user "the node you're submitting this particular query to does not support it" rather than just getting some kind of serialization/deserialization failure.

Talking of serialisation/deserialisation, consensus side we would then take the following approach:

* Encoders for "extensible" types such as the local state query (but also, say, all of the HFC types) don't do anything special. They don't check version numbers at all, and just encode.
* The corresponding decoders all use a tag to distinguish between the different queries/eras/..., and so can report a sensible error when they get an unexpected one: "Unexpected query tag such-and-such, probably you need to adjust your version bounds or upgrade your software" or something along those lines.