Define a compact representation of the command system

[liquiddandruff]

Currently the commands implementation parses a string to determine what commands to run. For example, passing the string task suspend radio into checkAndRunCommand(char *cmd) will call the "task" command with arguments "suspend" and "radio", which will be further interpreted within the task function as encountering a sub-command "suspend" with argument "radio".

This was fine when the commands were only called through UART (serial), but since we plan to schedule commands to be run in the future, keeping command strings such as task suspend radio in memory for extended periods is inefficient. Having a more compact representation will also help the radio link budget.

Notes:

• Decide between...
  • spreading out a command into separate arrays (eg, CMD_NAMES, CMD_FUNCS) such that an index X references the components of command Y (like in our current implementation)
    • seems like the better option, since we can index with X which is faster than scanning an array of structs as below
  • or defining a struct with members that self-contains a single command, and construct an array of instances of such structs to contain our commands
• A command can look like this...
  • 4 bits for the command
  • 4 bits for subcommand
  • 10 bytes for arguments?
  • facility for way to express large arguments? for ex, in cases of uploading new config registers, etc

[liquiddandruff]

Done now.

Radio uplink/other areas of the system can now initialize a struct to represent a command instead of a string. String commands from UART are now also parsed into the corresponding compact command representation, with cmd_id and subcmd_id specified using natural words, and cmd_data as hex strings.

For example, the following representation is 12 bytes (with 10 bytes unused)

	CMD_t cmd = {
			.cmd_id = CMD_TASK,
			.subcmd_id = CMD_TASK_SUSPEND,
			.cmd_task_data = {
					.task_id = TASK_BLINKY
			}
	};

and is equivalent and formed from > task suspend 40, where 40 is a hexadecimal string literal parsed and type-punned via union into cmd_task_data. 40 is the first byte in cmd_task_data, of which the first nibble is task_id. task_id then has a value of 4, which is the int value of enum TASK_BLINKY. Subsequent data fields in arbitrary commands can then be populated in this way.