[#1405] Modify trait utilities to support prefixed trait keys & add SelectChoices

[arbron]

• Modifies a number of utility methods in trait utilities to support prefixed trait keys (tool:art:potter instead of just potter)
• Introduces the SelectChoices type which offers a number of methods for filtering, sorting, cloning, etc. nested sets of options like those represented by tool categories

[Fyorl]

I can't help but feel like we perhaps wouldn't need to do quite so much work in Trait if we had more consistent and predictable structuring in our CONFIG as well as for where traits are stored on the actor. I'm not sure there's enough of a tangible benefit to changing it though at this stage given how much churn and breakage it would cause.

It seems that we only really ever have one level of children in our current trait configuration. I wonder, then, if having a fully-recursive tree structure and associated operations is necessary, and if there are maybe some simplifications that can be won from recognising this property. It might be that the general tree solution is the simplest though.

In general though I think it's fine that this complexity is tucked away in these utilities. It's an acceptable place to be currently.

If I could ask though for some small examples as to some of the inputs and outputs for the SelectChoices class, particularly in regard to how the wildcards work. That would help me a lot with contextualising some of this work. Since it's all sets of strings I'm hoping they won't be too arduous to produce. We could also include them as @example annotations.

Some examples for some of the trait methods would also help me, like you have in choiceLabel, they were very useful.

[arbron]

I can't help but feel like we perhaps wouldn't need to do quite so much work in Trait if we had more consistent and predictable structuring in our CONFIG as well as for where traits are stored on the actor. I'm not sure there's enough of a tangible benefit to changing it though at this stage given how much churn and breakage it would cause.

While I think it would be okay to switch things on the actor side, any major change of the config would be a breaking change for any 3rd party content that adds new types.

It seems that we only really ever have one level of children in our current trait configuration. I wonder, then, if having a fully-recursive tree structure and associated operations is necessary, and if there are maybe some simplifications that can be won from recognising this property. It might be that the general tree solution is the simplest though.

We do have the chance of multiple levels when more than one trait type is represented, which mainly comes into play with expertise (e.g. you get a choice between gaining expertise in a any skill or thieves tools).

If I could ask though for some small examples as to some of the inputs and outputs for the SelectChoices class, particularly in regard to how the wildcards work. That would help me a lot with contextualising some of this work. Since it's all sets of strings I'm hoping they won't be too arduous to produce. We could also include them as @example annotations.

Added some examples for filter and exclude.

Some examples for some of the trait methods would also help me, like you have in choiceLabel, they were very useful.

Add a bunch and moved the examples into the JSDocs.

[Fyorl]

Looks pretty good to me, thank you. I've left some minor linting comments and some suggestions for consideration, that you can take or leave.

[Fyorl]

Just one comment above about adding documentation then feel free to merge.