Add MANY_GAME_PROFILES parameter, repurpose GAME_PROFILE to only return one.

[dualspiral]

SpongeAPI | SpongeCommon

---

This is kind of me updating/fixing/thinking about things as I write Nucleus for API 8.

Two reasons I've made this a PR specifically:

• I don't want to tread on @Zidane's toes while the registry changes are underway. I don't know how close it is to being done. This isn't urgent and I can fix this up once that's merged.
• The use of Collection in Parameter.Value<> and whether we want to think about that a little - this is a thought that's come to mind as I've been building Nucleus for API 8.

On that latter point, we have some Parameter.Values that return Collection<T> rather than just T.

It can be argued that this is a good thing in that it clearly specifies whether a parameter will potentially return multiple entries or not. However, it might be confusing when it comes to CommandContext#getOne vs. CommandContext#getAll. When this parameter value/key is used in these methods, they will return Collection<T> and Collection<Collection<T>>, and this might be confusing to some people used to the old system.

As an example, say we have the following parameter:

final Parameter.Value<Collection<GameProfile>> profile = Parameter.builder(new TypeToken<Collection<GameProfile>>() {}).parser(CatalogedValueParameters.MANY_GAME_PROFILES).setKey("profile").build();

If we specify this once in a command then invoke the command, to get it from the resulting context, we'd need to use the requireOne method:

final CommandContext context = ...
final Collection<GameProfile> gameProfiles = context.requireOne(this.profile);

This makes sense because you're getting one parsed result. However, if you were to have this parameter twice (or more) in the command, you'd use getAll...

final CommandContext context = ...
final Collection<Collection<GameProfile>> gameProfiles = context.getAllthis.profile);

As you can see, you get a collection of collections. While this makes sense as what you're doing is getting multiple result sets from the separate parameters, it might trip people up and I just wonder if this is really what we should be doing. Do we want to perhaps remove the notion of Collection from some of these value parameters and basically assume that all parameters can return multiple values, or do we want to enforce returning a Collection when we could be returning multiple values?

I think I like the latter. I'd just have to make some of the javadocs and docs examples (when I write them) clear about what's going on.

(I'm also not inclined to change it because a) it's getting late in the API cycle and b) it would actually be painful to implement because of the way Brig works and how I'm trying to keep some sembelence of compatibility. I thought I'd mention it, however, because it also gives some context to the change I'm making in the first place!)

I'll merge this when registry changes are done or if Zidane is willing to add this into his changes.