Look into cleaning up multi-protocol support

[sisuresh]

At the moment, the code has support for setting a range of protocol versions supported by env (example). This was done back when we required backwards compatibility with previous protocols, but now we just package a new env per protocol release, and no longer require backwards compatibility.

There are a couple things we should look into removing -

1. The TEST_PROTOCOL environment variable and any related code.
2. Code used by the "next" feature. I don't think we can remove the feature itself because it's used to activate xdr staged for the next protocol.

Before we do any of this, we should make sure we're fine with removing multi-protocol support in env. I think it's fine to remove, but I believe we've discussed using this functionality for small protocol changes to reduce the number of hosts in core. That doesn't sound like a good idea due to complexity, but wanted to point it out.

[graydon]

yeah I'm not .. sure. we do still have the premise of one soroban being used in core to handle multiple protocols (which we'd decide "if it works" by checking old closed-protocol ranges to see if they replay on newer sorobans and compressing down the set of sorobans).

but I'm also not sure that if we do that it'll benefit in any way from the separate multi-protocol support in rs-soroban-env. like the whole point of "one soroban can replay multiple old protocol ranges" would be .. that a single un-varying soroban release can replay multiple ranges. even if that soroban release has some internal version-gated logic, that would switch without any of the in-repo support for multiple protocols.

if we did get rid of support here, we might be able to purge the multiple protocol-specific observation directories too.