Add profile cache

[Jikoo]

Trades a relatively small amount of disk space (about 50 bytes per player) and additional async processing post-login (which is generally a hot area for plugins already) in exchange for not relying on the server's user cache or having to load every single player from disk to check their name.

There is one behavioral change here - for the SQLite implementation, I opted to require the first character to match (case-insensitive) as it provides a massive speedup to the already-much-faster query.

TODO:

• Expose PlayerLoader's ProfileStore getter and setter to allow third party implementation (and make sure to log w/ class when used!)
  • I've elected to not make this official API for now because I'm still on the fence about it. I will likely not resolve this until I also expose allowing custom player loader implementations.
• Consider refactoring JdbcProfileStore
  • Removed; it would have to be rewritten to handle connection pooling anyway.
• Consider refactoring importer to allow importing from arbitrary other implementations
  • Requires a getAllProfiles method
  • Given that this is not going to be official API yet, I don't want to bother for now. There will likely need to be events created for starting and finishing imports and things of that nature.
• Consider adding a method to get profile by UUID
  • Just get the player directly
• Consider adding profile expiration
  • last_update exists for this
  • For now I don't want to bother with expiration. I don't see it as a particularly desirable thing to force lookup via UUID for profiles over a certain age. People who are interested can manually run a delete query using the provided field.
• Consider WAL
  • WAL offers a not-insignificant performance improvement. During normal operations, we only ever write with the one connection. Needs extra handling during shutdown.
  • After some consideration, I don't want to use WAL. While the database location currently is not configurable, I could see several server instances behind BungeeCord et al using the same database. Using WAL would cause a lot of extra headache there. Users who do want to enable WAL are free to do so manually.

It may be a good idea to optimize the JaroWinkler implementation in a future PR - that's likely the largest bottleneck now.