Adding a simple gofmt alias.
Enabling caching. Oops.

The server was not setting any cache directives at all, and Volley interprets
this to mean not to cache (which is a reasonable, conservative approach.) So,
this CL adds cache directives, and also puts the ID for photo lookup path
(i.e. /photos/<event-id>) so that each event has a unique URL and are thereby
cacheable at all.
Reimplement config handling.

The current database schema and modeling of sensors is inadequate, and needs
to be refactored. However, the various type definitions for sensors were
located in "providence/common", which also included config stuff, the
signature definition for top-level handlers, and a hodgepodge of init code. In
short, common had scope creep and has become unwieldy.

So, this CL splits out config, types, and actual runtime-common stuff into
separate packages, and updates config accordingly. Also improves how config
handling and loading works (i.e. config.json no longer needs to have a value
for every possible field, if the default suffices.)

Runs and seems to work, but not thoroughly tested.
Adding a QR code URI for client config.

After a corresponding barcode-scanning UI is added to the Android app, this
will enable a device to get config data from scanning a page generated by the
server. This will permit config loading/updates without having to reinstall a
new .apk.
Configure Android app via QR code generated by server.

Adds a server URL path handler for /qrconfig that generates a QR code packed
with a Java properties block, intended to be scanned by a phone app to
populate its configuration. Previously, this config information was hardcoded
into the .apk. This makes development (as well as) publication/distribution
harder, as it means replacing files and rebuilding a .apk to switch to a new
server (e.g. prod vs. dev, or for others if someone picks up the code.)

So, now on first launch the app will automatically launch Barcode Scanner (or
prompt to install it and then launch it), and then load its configuration by
parsing the resulting Java properties string.

It's worth noting that the QR code includes the actual base64-encoded
server (pub-key) cert keystore. Since the app supports self-signed certs,
there needs to be a way to load the BKS keystore as config data. I thought
about having the server simply serve its own BKS, and have the QR properties
block include only a URL to the BKS; but there is no way to do this without a
MITM vulnerability. Fortunately the BKS can fit into a QR code along with the
other info, at least for a small BKS with just one cert pub-key.