Feat/bit operations

[CJDevZ]

This PR adds support for the following operations in the operator argument:

• &=
• |=
• ^=
• ~=
• <<=
• >>=
• >>>=

These are useful for datapack/command expressions involving bit manipulation.

The implementation appends these to the existing suggestion list and updates the argument parser accordingly.

Let me know if you'd like additional operators or code style adjustments.

[SB2DD]

I've tested this change and it's pretty cool. Although I have a big issue with the fact that the client-side parser isn't actually "changed", which unfortunately makes the rest of the command (after a custom operator) look red, even if it will execute and the rest of the suggestions will work.

It will also create some complications on our side for implementing this change onto the code editor's completions...

I know this might sound hacky but maybe you could change the argument type to be of a string instead (whilst keeping the suggestions) and adding some custom parsing to get the string to get the same functionality as before? I feel like this would fix the red-ness issue, but I'm worried this wouldn't help us a ton with the code editor..
Otherwise, maybe trying to use literals for the operations could work too? (sort of how /data modify works??) This would 100% fix both issues, but this could be a significant change to the scoreboard command that might even affect the colours of the parsed command, which could possibly throw off some players..

At this point, I'm not too sure what to add more to this, so I might leave it up to @Remynfv to see what would be best for this PR.

[CJDevZ]

Side note: bitwise operators are also helpful for inspecting IEEE-754 floating-point
layouts (sign/exponent/mantissa). Not required here; just a potential use case.

[Remynfv]

OK, first, the implementation looks very clean. No criticisms there. My hesitance to respond to this is mostly because I don't feel it gives a large enough benefit to enough people. I think 99% of players would just be confused by these extra parameters.

For the remaining 1%, I don't think this offers enough unique behavior. If I'm not mistaken, all of these functions could be implemented with some arithmetic functions...? Correct me if I'm wrong though.

To make maintenance easier, I also try to avoid implementing anything except necessary patches in the server jar. This is something that needs to be done through an LSP patch, but for the relatively small use, I just don't think it's worth adding another patch.

If this were to be added, it would also have to hook into the LSP settings to check if the custom datapack features flag is enabled, because without it, we want to maintain 100% vanilla behavior. Right now though, I don't see myself merging this, despite the fact it's pretty cool.

If you can show me some counterexamples of things not being replicable with existing scoreboard functions, or if there is a large community demand for this as a quality-of-life feature, then that could be grounds to re-open this PR.

(P.S. if you contribute more features to LSP in the future, feel free to discuss your idea on the Discord with me to see if it's something we can use!)