Add Tokenized Command Argument Parsing

[LavCorps]

In the face of the dedicated effort for 2.0, this issue serves to detail a speculative thought so that I may get the idea out of my head and redouble my focus on current efforts.

The idea is, on paper, reasonably simple: Replace the ad-hoc string parsing using iterative lookups (old-style) or arg slicing (new-style) with a single, consolidated parser class. As part of this effort, all commands are provided a "pattern" that arguments follow. Example patterns are listed below. Ideally, they would be a single line for whitespace sensitivity, but for display, they are broken up into multiple lines.

<!-- drop_player.js -->
<pattern>
  <token type="InventoryItem" attribute="name" id="item"/>
  <optional> <dynamic related="destination" attribute="preposition" default="in"/> <token type="Fixture|InventoryItem|RoomItem|InventorySlot" attribute="name|id" id="destination"/>
    <optional> of <token type="InventoryItem|RoomItem" attribute="name" id="destination_container"/></optional>
  </optional>
</pattern>
<!-- instantiate_moderator.js -->
<pattern>
  <token type="Prefab" attribute="id" id="prefab"/> in <token type="Player" attribute="name" id="player"/>'s <token type="EquipmentSlot" attribute="id" id="slot">
</pattern>

"token" elements have three attributes: type, attribute, and id

• "type" refers to the type of alter ego object to match
• "attribute" refers to the attribute of the object to match, and should be a string
• "id" is the id of the token, for reference in javascript and for reference by "dynamic" elements
• these are used similar to regex groups

"dynamic" elements have three attributes: related, attribute, and default

• "related" is a token id to refer to
• "attribute" is the attribute that the element should represent, and should be a string
• "default" is the default
• these can be used to narrow argument parsing to match the preposition of a token

Token attributes and types can specify multiple values, delineated by |. Patterns are provided to the parser and in command config as a list of strings. Guards against undefined values should likely be taken, to ensure that optional tokens are always defined (Consider the utility of the Discord.py discord.utils.MISSING sentinel).

I don't expect this to be an issue that sees attention until at least the release of 2.0. Despite that, I do think tokenized argument parsing, or at the very least standardized argument parsing, would be a great benefit to command maintenance and future command development.

—♥️

[LavCorps]

We can likely roll this into the future optimizations v3 branch slated for post-2.0, but I want some hard limits on time complexity. If we can figure out a design for a parser that brings it below polynomial time, then I would happily roll this into optimizations v3, but otherwise, the performance losses are just too significant regardless of how much it would improve developer quality of life.
—🫧

[LavCorps]

The natural first step in this endeavor should be to investigate the MUD servers of old, or perhaps legacy Discord text command bots. I do not think the wheel needs to be reinvented for this endeavor, merely refitted.
—❄️

[LavCorps]

We can likely roll this into the future optimizations v3 branch slated for post-2.0, [...]
—🫧

As per the 💾 standards of branched development, this feature will be given a separate branch just for it, if it can pass the given requirements.
—❄️

[LavCorps]

Consider coordinating development of this in tandem with #204, such that natural language parsing can also be localized with per-language grammar.
—❄️