Community edition

[Electroid]

Figuring out what belongs in PGM and what doesn't is a tricky balancing act, and it's been difficult in the past. On one had, PGM works great "out-of-the-box" with features such as /a or settings. On the other hand, recent proposals and issues for #300, #305, #317, #280 highlight that putting them all in one package might be problematic in the future.

For developers:
I've already started breaking up PGM into "maven modules" such as api, core, util, and now I am considering adding a new module, community, which is essentially a "catch-all" for things that are useful for "scrimmage servers" but do not need to be in core.

Existing features like /report would be moved to community and recently rejected proposals for /punish, /freeze, and other moderation tools would be allowed back under community.

The community module would be slightly special, because it optionally depends on PGM. You can run the Community plugin without PGM, say on a map development server, but if PGM is present, then extra functionality that requires Match access would also be present. This module could also depend on util so we don't have to reinvent the wheel with translations and other things.

For users:
Commands like /report, /punish, /freeze and other continue to have support and default functionality in PGM. Commands like /vanish would be reconsidered under the new community scheme.

For server owners:
The PGM jar has the community module included by default, with an optional config option to remove it. The community jar would also be available for a separate download, for other use cases such as map development servers.

User and developer feedback is important, as well as compromise for a project like this one. It may take some time to get the module separation onto master, so I would be willing to fast-track some of the rejected moderation PRs and refactor them out later. Comments and feedback would be great!

cc @applenick @Pablete1234 @Brottweiler @KingOfSquares @AustinLMayes