Integer values for attributes

Using integers for most output attributes might reduce vector tile file size in a number of ways. First off, an integer in and of itself is stored more efficiently than other, higher precision formats. Secondly, @yhahn indicated in conversation that if attributes are repeated across features within a vt, that value is effectively only stored once.

I see two ways to handle this:

1. Always force integers. Downside of this is attributes with actual higher precisions (eg a field that ranges from -1 to 1, as do many pixel indices). Of course, this could be handled by the user scaling these values before encoding, but.
2. Build into the variable --> band mapping. Right now, to specifically map a band, we pass an option like so:
   -b <var name> <band no>
   We could easily make this into:
   -b <var name> <band no> <precision>

cc @ian29 @MateoV

The issue names no files, tests, or entry points; start by tracing the variable-to-band mapping and current -b <var name> <band no> option handling. Review how output attributes are encoded and compare the two proposed precision approaches. Done criteria are not defined because the issue does not choose an approach or specify expected behavior.