[WIP] Add CommandResult

[boformer]

Continuation of #409 and #524

This issue explains what command stats are used for: #326. I don't know why it was closed.

This PR replaces the boolean that is returned when a command is called with a CommandResult object, which stores the command stats SuccessCount, AffectedBlocks, AffectedEntities, AffectedItems and QueryResult. I also added a Map for custom data.

The CommandResult is passed with the CommandEvent after the execution of the command.

The implementation is based on @AlphaModder's pull request, but uses classes instead of interfaces to make it easier to use the system (similar to the Text API).

The only thing that changes is that plugin developers now have to use a builder to create a CommandResult:

MyCommand implements CommandCallable {
    CommandResult call(CommandSource source, String arguments, List<String> parents) {
        ...
        return CommandResults.processed(); 
        // equal to CommandResults.builder().setProcessed(true).build();
    }
    ...
}

I'm not sure if this is the best way of implementing it. I also thought about a system that uses separate classes for each result data type (similar to the Data API proposal):

CommandResult {
    boolean wasProcessed();
    <T> Optional<T> getData(Class<T extends CommandResultData> clazz);
}

[stephan-gh]

The code style is wrong in some files

[Deamon5550]

Need better docs here for what the query result is.

[boformer]

Right now there is a problem with this setter (tests fail).

Should I change it to setResult(Optional<CommandResult> result)?

[ST-DDT]

No Afaik the optional is only for return types.

[boformer]

That's true, but the event system does not work if the setter does not use the same type.

[simon816]

You haven't added the key 'result' to the SpongeEventFactory

[zml2008]

I'm not sure about even having the processed flag in here. If we go with what I proposed in #551, the SimpleCommandService call method can handle all the logic of calling the event and printing not found messages if necessary.

I definitely think adding a map for custom attributes is too much at this point in time. If somebody can give an actual (meaning something they're trying to do in a plugin), specific use case for it that is a lot more complicated without, then we can always add it in later.

Also, you should expand on your javadocs to explain what each value does in terms of the game (like: entities affected is entities matched by arguments, success count is entities successfuly affected (why? who knows)

I'll put in a few line comments on other little things.

[zml2008]

This should be private or package-local (no spec) or this class should be marked final. We only want people instantiating it through the builder

[stephan-gh]

public?

[Zidane]

This is now a part of zml's Commands Overhaul PR. Closing.