Figure out a better way to refer to features in protocol implementations

[qdot]

Due to actuation commands (scalar, rotate, linear) having been the way we defined all device functionality before the new config in Buttplug v8 and now the Device enumeration messages in spec v4, protocol implementations just kind of assume they're going to get a list of actuator commands in some sort of set order. This order is never really defined anywhere, and it's not set in the messages; a scalar command could send two vibration actuator feature indexes in reverse order, and we have to know on the server end to sort all of the commands by feature index, and then group the commands by actuator type.

Either this procedure needs to be well documented somewhere, or we need to figure out how to make some way to denote exactly which features we're talking about when we implement protocols. I don't see this requiring something like a UUID per-actuator (as we have thousands of those now probably, between different toys on different brands), but possibly some sort of Endpoint style naming that we could use across protocol implementations, like Vibrator1, Vibrator2, Rotator1, Linear1, etc... This is almost mostly a problem for scalar commands with similar actuator types, as we really haven't seen anything with multiple rotator/linear actuators yet.