Add "next" feature to crates using xdr directly or indirectly

[graydon]

Stellar-core has support for developing "two versions at once" of the protocol: a "curr" version which is soon-to-ship (for point releases, hotfixes or work we're very certain we're done working on) and a "next" version which is experimental / not-to-ship. These are both available in the same codebase and switched between using flags, not branches. The point of this arrangement is to avoid having to maintain potentially-diverging branches (at least of most of the code, the XDR is branched): most code can have everyone work on head and just switch configs when we switch tasks between future-work and current-release work.

This PR adds support for this curr/next split to the env crates, selectively enabling either the curr or next XDR and adjusting the declared protocol version (and unfortunately also all the test wasms compiled against those).

It may seem like it might be overkill, but there are 3 increasingly-serious reasons why I think this is necessary:

1. We are likely to want the same curr/next split while working on future env stuff and simultaneously releasing env hotfixes. Branching would be worse.
2. There's a bunch of inter-subsystem checks of "equal protocol versions" (between core and env, between env and loaded contracts) that we'd have to disable in a next-build if we wanted to not have this. We could add a runtime flag to the env that disables those checks, and set it in a next-build, but this would be a bit of a footgun. And if we made it a compile-time flag that .. would be adding a feature. Which is what this PR does.
3. Most seriously: when we switch core to a next build, it switches the XDR it's looking at from the curr to next branches of the XDR repo. If env keeps looking at the curr XDR, it won't be able deserialize "next"-introduced XDR passed to it by core, much less use any features present in that "next" XDR.

Obviously this is not the only way forward, and there's a limit to how far we take it (eg. apparently horizon prefers to work on branches and this is not going to propagate through to them) but .. I think given the arguments above this is the right current choice.