Improved PluginMessaging API by adding a method to easily encode the data to be sent

[4drian3d]

partially implements https://github.com/PaperMC/Velocity/issues/224

final ChannelMessageSink target;
final ChannelIdentifier identifier;
final boolean result = target.sendPluginMessage(identifier, (output) -> {
    output.writeUTF("some input");
    output.writeInt(1);
});

[Joo200]

Is it worth to replace the Consumer with a functional interface? Could be cool to make your own writable class or record. E.g.

target.sendPluginMessage(identifier, myDataRecord);

Implementing a Consumer in a class or record can create limits and an additional functional interface doesn't hurt

[4drian3d]

Is it worth to replace the Consumer with a functional interface? Could be cool to make your own writable class or record. E.g.

target.sendPluginMessage(identifier, myDataRecord);

Implementing a Consumer in a class or record can create limits and an additional functional interface doesn't hurt

done

[McModknower]

There are some seemingly unrelated style changes: moving ComponentLoggerProviderImpl and adding final to some variables in https://github.com/PaperMC/Velocity/pull/1254/files#diff-c10d0c7c0eae67f7aa521775123b1a13969c0bcbdd1da5126ff5f1034c35301eL273-R300 and other places.

Is this normal procedure for contributing to Velocity or are these changes not intended?

[4drian3d]

There are some seemingly unrelated style changes: moving ComponentLoggerProviderImpl and adding final to some variables in https://github.com/PaperMC/Velocity/pull/1254/files#diff-c10d0c7c0eae67f7aa521775123b1a13969c0bcbdd1da5126ff5f1034c35301eL273-R300 and other places.

Is this normal procedure for contributing to Velocity or are these changes not intended?

These are too small internal changes that are not worth including in a separate pull request