Be a little more concise about when we need to run migration for v64.

Before it is not apparant that the migration introduced for v64 is associated with that particular version. This is because the guard condition used to bail out from the upgrade is more closely related to a previous migration.

This is due to a flaw with the desigh of resetTransient(), whereby it always resets the database to the schema of the current F-Droid version being run, not of the tables as they stood at the time of the particular migration being introduced.

This clarifies the guard condition for v64 by allowing it to query whether the schema has been created fresh or not during this particular invocation of onUpgrade()

Note: this is less to do with the v64 migration, but rather I came across the exact same issue while working on category table related changes. At that point I realised I made a slight mistake with the resetTransient() method.

Also: I'm happy to entertain other designs if anybody is that interested. One other approach is to change the guard condition to:

if (version >= 64 || fieldExists(db, ApkTable.NAME, "...")) {
  ... add field ....
}

However that suffers a little bit when the migration is a little more complex and checking if a field exists may not be enough.