Add version numbering to dev builds

[schuyler]

NOTE: This PR was doing too much and so I've split the CircleCI refactoring out into #406. This PR should be not be merged until after that one.

Issues:

Closes #401.

Scope:

• Add APK version numbering for dev builds based on CircleCI build number.

Requested reviewers: @zestyping

User-visible changes

Both dev and release builds will have a version code and a human-readable version string.

Builds made from the command line will DTRT if the developer runs ./gradlew -DversionNumber=$(.circleci/get_package_version) assembleDebug.

[zestyping]

Why omit z here?

[schuyler]

Our app/build.gradle expects versionNumber to be in the form <major>.<minor>.<patch>. If we want the build number to appear in both the versionString and versionCode, it has to go somewhere, and I figured replacing the <patch> number of the latest release was the most innocuous way to do that.

The alternative would be to continue to append the build number to the original versionNumber but then (a.) build.gradle would need to be updated to permit that and (b.) the versionCode wouldn't change between dev builds. (Maybe that's actually what we want?)

[zestyping]

First, just to be clear on terminology, the fields are named versionName and versionCode.

The only practical effect of the versionCode is to prevent unintended downgrades. The Play Store will only perform automatic updates that increase the versionCode. As far as I know, only the Play Store enforces this; the phone doesn't care whether the vesionCode increases or not. Because we don't plan to ever publish development APKs to the Play Store, in some sense it doesn't matter what we use for dev builds.

Any of these choices are fine:

• Set versionCode to 0 for all dev builds
• When versionName is x.y.z, set versionCode to 1000000x + 10000y + z for all dev builds
• When versionName is x.y.z at patchlevel p, set versionCode to 1000000x + 10000y + 100z + p for all dev builds
• When versionName is x.y.z, set versionCode to 1000000x + 10000y + p for all dev builds

The first is the simplest (it's what build.gradle currently does, and I think it will work fine—the net effect is that any production release will supersede (automatically install over) any development release.