Expose certain scoreboard related argument types

[Strokkur424]

Closes #12540

This PR exposes a few scoreboard related Vanilla arguments for use in-API.

• OperationArgument
• ScoreHolderArgument
• ObjectiveArgument There is no reason to expose the Vanilla one, as that one is just a wrapper around a string argument.

Operation Argument

Example usage: Implementing a simple /compute command.

Preview:

Code:

Commands.literal("compute")
    .then(Commands.argument("left", IntegerArgumentType.integer())
        .then(Commands.argument("operation", ArgumentTypes.operation())
            .then(Commands.argument("right", IntegerArgumentType.integer())
                .executes(ctx -> {
                    int left = IntegerArgumentType.getInteger(ctx, "left");
                    int right = IntegerArgumentType.getInteger(ctx, "right");
                    Operation operation = ctx.getArgument("operation", Operation.class);

                    ctx.getSource().getSender().sendRichMessage("The result of <left> <operation> <right> is <result>!",
                        Placeholder.component("left", Component.text(left)),
                        Placeholder.unparsed("operation", ctx.getInput().split(" ")[2]),
                        Placeholder.component("right", Component.text(right)),
                        Placeholder.component("result", Component.text(operation.apply(left, right)))
                    );
                    return Command.SINGLE_SUCCESS;
                })
            )
        )
    )
    .build();

ScoreHolder Argument

Example usage

Preview:

Code:

Commands.literal("testscoreholder")
    .then(Commands.argument("scoreholder", ArgumentTypes.scoreHolder())
        .executes(ctx -> {
            ScoreHolder firstHolder = ctx.getArgument("scoreholder", ScoreHolderResolver.class).resolve(ctx.getSource()).stream().findFirst().get();
            ctx.getSource().getSender().sendRichMessage("Found <holder>", Placeholder.unparsed("holder", firstHolder.getScoreboardName()));
            return 1;
        })
    )
    .build();

[lynxplay]

In general, I'll poke some other team members about this, so I'd wait a bit with implementing my feedback given how drastic it is.

[lynxplay]

These methods are just copies from the ones above?
What is the point of these?

[lynxplay]

In general I am not much of a fan of this split between SimpleOperation and Operation internally.
apply(int, int) is only defined on simple operations. This makes it seem like it is universally applicable (which it isn't, CommandSyntaxException is thrown for the swap operation).

Having to pass all this BS just to construct a ScoreAccess also seems overkill.
Plugins will not be using scoreboards to store/modify their data.
I think we'd be better off on implementing ScoreAccess in our own type with a noop display name / override.
That way we can a) have apply(int, int) be always functional and simply return the "target", or "left" side here.
We could also expose an apply(int,int)Int2IntPair that yields both for people caring about swap.

This scoreboard/objective based method seems just very very useless/cumbersome to work with.

[lynxplay]

All the downsides mentioned in the API type apply here but review of this without changes to the API type is pretty useless.

[lynxplay]

Given I believe this requires a restructure, review of this isn't needed.