Refactor database schema constants
**Note:** When this is merged I'll rebase !347 and remove its WIP.
## Summary
In order to do the database changes required for #511, I've found that it is difficult due to my inclination to switch between referring to database columns by either a Java constant such as `AppProvider.DataColumns.NAME` and string literals such as `"name"`. All string literals should be migrated to constants, and that will happen in my next MR. In order to prepare for this, I've gathered together the constants into one common place: `org.fdroid.fdroid.data.Schema`. This is going to be the authoritative place for the schema to be stored going forward, and will help when reasoning about the database structure.
Although it seems large, this change is a fairly straightforward find/replace job. It also passes all tests for which there is good test coverage in the content providers.
## Changes
Create `Schema` interface to make it simpler to replace string literals with constants.
Right now, table names are in `DBHelper.TABLE_*` constants, and each tables fields are
in `*Provider.DataColumns.*` constants. This brings them all into a predictable location.
In addition, it makes it easier to statically import `Schema` so that instead of, e.g.,
* `AppProvider.DataColumns.PACKAGE_NAME`
We can choose one of the following, based on our current context:
* `Schema.AppTable.Cols.PACKAGE_NAME`
* `AppTable.Cols.PACKAGE_NAME`
* `Cols.PACKAGE_NAME`
In the worst case, it isa couple of chars shorter than now. In the best case, if we are
writing a class that primarily deals with Apps (e.g. App.java or AppProvider.java) then
we get a big win with just `Cols.PACKAGE_NAME`.
Having these things slightly shorter may seem like it is pointless, but the length of
each constant probably contributed to my lack of willingness to use constants instead
of string literals when constructing queries.
In the future, this should be moved towards something more akin to:
> http://openhms.sourceforge.net/sqlbuilder/
and I hope that extracting all the schema stuff into one interface may help that.
See merge request !346
3fae57c360