Fix edge cases to allow sqlite backend

[nouish]

This makes some non-breaking changes to DatabaseDataStore to let it work with a SQLite database. These changes make absolutely no difference with MySQL, besides no longer logging a warning the first time GP is 'installed'. For more information, see the referenced issue comment below.

Changes:

• SQL constants are now actually constants. This resolves an error suppressed as a warning, where the first time running GP, it would first fail to set the schema version, as a result of deleteSchemaVersionSQL being null. This is suppressed by MySQL, as the driver throws SQLException. Xerial's SQLite driver would throw NullPointerException, which was not suppressed.
• Removes trailing ;s from SQL statements. These are pointless, and when batching, could cause problems, as MySQL driver sometimes fails to rewrite these (when rewrite enabled). Not a current concern, but regardless.
• Don't bother with Class.forName(driverName) as this has been unnecessary since JDBC 4 - which came with Java 6!

With this PR, GriefPrevention may be configured to use SQLite, using GriefPrevention.Database.URL: jdbc:sqlite:database.db, but I don't see this as being "proper" support for SQLite, however.

Reference: #1068 (comment)

[RoboMWM]

Am presuming you tested with data from an existing mysql database?

[nouish]

Am presuming you tested with data from an existing mysql database?

Indeed, using a backup from a friends server dated April 25th, containing 3739 claims and 5438 players.

This PR contains no logic changes, besides making the ALTAR TABLE statements only run under the MySQL driver, leaving no regressions for MySQL.

All this does is clean up raw SQL (removing trailing ;s) and move them to static final constants, which stops DatabaseDataStore.updateSchemaVersionInStorage(int) from logging a warning (unsuppressed NPE in SQLite driver) the first time GP is run.

---

For what it's worth, I would like to see automated tests for MySQL integration, as that will absolutely help future improvements here. If someone could provide a really old, early version data set then that could be used to verify migration to newer schemas. If not, I have no problem using the database I used to verify this, but it was first created October 2019, meaning it was created in the current schema.