Update Safety Wall API

Description

Changed the API for spawning safety walls (while maintaining backwards compatibility) so that we are less likely to encounter bugs with the safety wall spawning behavior in the future.

There were two ways to enable/disable safety walls. 1) Put a new SafetyWallPositions config to /session/safe_walls and change the value of the "enabled" field. 2) Put a new EnabledSystemsBitfield to /session/enabled_systems and change the SafetyWalls bit. This was confusing, and led to a situation where one of the options was working properly and one of them was not.

I have updated the firmware so the safety walls should only be enabled/disabled by changing the EnabledSystems bitfield, so we will only need to test the one method in the future. In order to maintain backwards compatibility, I have marked the SafetyWallPositions with "enabled" field as deprecated, but still allow it to be used. I have updated our client code (BurtSharp) to use only the EnabledSystems bitfield and will phase out the deprecated firmware feature in the next major version upgrade.

The other feature that I've added is the ability to change the enabled systems state without having to first check what it is, e.g. we just want to enable/disable/toggle the safety walls without affecting the other sub-systems like robot gravity comp, user gravity comp, etc. I added the CoAP routes /session/en_sys_set_bits, /session/en_sys_clear_bits, and /session/en_sys_toggle_bits, which take a 16-bit unsigned int that maps each bit to one of the systems that can be enabled/disabled/toggled. (There's currently 9 of them with the haptic elbow stop for ambidextrous arms.)

What to focus on

• Test this with the Sandbox program SafetyWallsTest, which provides keyboard interactions to test all the new safety wall behaviors as well as the new /session/en_sys_toggle_bits route (it lets you toggle safety walls this way)