Implement better version numbering

[tsmacdonald]

Currently, Macaw's version is set to 0.1.z, where z is the number of commits in the release since the beginning of time. This makes working with Metabase releases difficult: a backport for an old version of Metabase may depend on some new Macaw behavior, but there could also be breaking changes in the Macaw API. We need a more sophisticated versioning strategy. The proposal is semver-adjacent:

New scheme

1. [Continue to] use the x.y.z format.
2. x and y will be set in a new VERSION file that gets slurped by build.clj.
3. z will be the number of commits since x.y.0.
4. We will create a git tag for every x.y.0 release to help compute Get query's tables and columns #3.
5. x will be incremented when there are serious changes to the public API ("serious" is deliberately vague, but is meant to allow us to keep the same major version number if the API-breaking changes are trivially addressable from within Metabase)
6. y will be incremented when we feel we've written a substantial feature (this is again deliberately vague). This includes both very different internal behavior (e.g., improving our column-finding logic) or additions to the API.

[crisptrutski]

This was our first idea, but perhaps there's something even simpler we could do? Input welcome.

[crisptrutski]

I realize that technically we don't need the git tags if we rather use "number of commits since VERSION was last updated", which also seems a bit safer.