PlayerNameResolver has no concept of multithreading

[TheE]

The current PlayerNameResolver has no concept of multithreading, lookups are always done in the main server-thread. This is obviously problematic.

A better alternative could be to wrap results in CompletableFuturess and enforce an async implementation on the platform-level. (Sponge's GameProfileManager already works asynchronous.)

[TheE]

When tackling this problem a few other issues could be fixed as well:

1. In commands, players should be able to optionally give an UUID instead of a name (by prefixing UUIDs with u:), e.g. to uninvited a player who is not known to the server. To do this we need to re-add Profiles - but unlike the previous usage, Warp would not store Profiles but UUIDs. Done in 91cdc14.
2. Commands that require a name to UUID conversation need to work partially async. The implementation would wait until a UUID (or Profile) is acquired and than continue in the main thread. As of writing, the same operation results in a short block if the name is resolved from the SQLite cache on Bukkit.
3. Maybe we can also revisit the implementation of invitations. The commands could be greatly simplified if some common structure for groups and players were introduced (e.g. Domains). It might even be a good idea to have Warp only store individual Domain instances and delegate saving to the Storage. Done in 08cbad8.