Define branch/tag versioning strategy for repo(s)

[bdarcus]

This builds off of the discussion with @dhimmel in #215 to suggest the following (which the cpython project uses);

I have added a v1.0 branch, to accompany the v1.1 branch I setup a few weeks ago.

Going forward:

ACTUALLY, NOT SURE HERE

• any PRs targeted for 1.0 get merged to the new v1.0 branch; 1.0.x releases get tagged as such
• any PRs targeted for 1.1 get merged to the v1.1 branch; 1.1.x releases get tagged as such

Once we merge the v1.1 branch to master and tag the release, then we can do future commits to master, and merge back to v1.1 if we need to tag a 1.1.x release.

I think the same strategy (with potentially minor variations) will work for schema, documentation, and styles.

Note: not super sure on those last details, but hoping someone will correct me if I'm off.

[bdarcus]

I think, given the problems recently with doing development on the v1.1 branch, we should keep things as simple as possible going forward, and focus on master once we tag v1.0.2.

[denismaier]

I hope that development of upcoming versions will be a bit easier now that we've managed to closed quite a lot of the legacy issues. After 1.0.2 is done, we can really do develop on master and just tag accordingly when a release is ready.