Fix incorrect command node serialization by creating new Command

[Rickyboy320]

Fixes #11649 - As noted in the issue, when CommandNodes are serialized they are used as the key in a Map. Their equals()/hashcode() should only match if they are equal nodes (name & command), but due to the erasure of the command field pre-serialization, nodes with different commands can be mapped onto the same value. This causes the client to interpret both nodes as the same, causing suggestions where they should not.

This is fixed by creating a different no-op Command for the erasure, instead of them holding the same lambda.

[Machine-Maker]

This fix has created an issue. It breaks the compactness serialized size of the commands. For any plugin that uses "flat" aliases (aliases that just shallow copy the root literal), it now doubles the serialized size of the command tree instead of re-using the references to the children command nodes. This is because the hashmap that tracks a serialization id for each CommandNode no longer finds existing nodes because the Command instances are not equal.

[Rickyboy320]

I suggested another approach in the related issue, where we keep the original command in the node, so that the equality of the fake node matches the original node (and other copies thereof). I'm not sure what side-effects this has, however, since it seems like the command field is intentionally wiped

[lynxplay]

Yea we are presumably going to opt towards that approach down the line to avoid the tree reduction from failing as hard as it has been 👍 The approach here worked well enough, it was only ever exposed as an issue cause once a couple of other bugs were fixed as well.