Release SDK v1.0, guarantee backwards compatibility

[mollykarcher]

What problem does your feature solve?

This SDK version is pre-1.0, which implies that we may break the interface between versions without warning to developers. This means developers can't have total confidence in using it, and may need to make significant changes on their wide when just pulling in minor version bumps. It also disincentivizes our team from caring about maintaining backwards compatibility, which proliferates the problem. This SDK shadows the Horizon API, which is stable and defined a major version, so there isn't really a good reason why we would need to make significant breaking changes repeatedly to this SDK. Breaking changes can happen more frequently than horizon's API but it shouldn't be a free-for-all.

What would you like to see?

An official release on Github of this SDK that versions itself at >= 1.0. Going forward, we properly respect semantic versioning and will not introduce backwards incompatible changes without bumping to a new major version.

It would also be worth it (before officially cutting it) to do a bit of a holistic audit and cleanup here, to make sure we are confident and proud of what we release as 1.0.

What alternatives are there?

[overcat]

I plan to release the stable version 1.0.0 with the launch of Protocol 22.