Add optionally assignable labels to variables

[zorgiepoo]

This fixes #66 and #16 by allowing users to assign labels to variables in the table, and allowing other variables to reference labels of other variables in their address formula.

More details:

• An "Edit Variable Label" option is added to add/alter a label of an existing variable.
• An "Edit Variable Labels" (plural) option is added for add/alter multiple labels; $n token is used to give labels a different number. Conventionally it should be at the end of the variable name, e.g Foo_$n will create Foo_0, Foo_1, ...
• Labels accept characters in ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_$
• A label("...") function is added when evaluating address formulas via DDMathParser, which does a lookup to see which variable in the table (if any) has the specified label and returns its current address
• In scripting, debug.updateVariable(label, addressStrOrNum) and debug.variableAddress(label) are added for updating the address formula of a labeled variable and for retrieving the address of a label respectively. Updating a variable currently contributes to creating undo/redo actions in the variable controller even via scripting.
• An empty label is the same as no label. Variables initially have no label.
• Multiple variables cannot have the same label. This is validated when variables are being added from a re-do as well as when altering an existing variable label.
• Labels participate in automatic variable description annotation. Assigning a label to a variable will automatically annotate the label in the variable's description as the first component. Using a label in a variable address will show a dependency relationship in the variable's description (e.g, -> Label Foo), unless that variable is also labeled in which case only its label is shown. Annotations of variables in the table are updated when labeled variables are added, removed, their labels are altered, or when a variable address that uses a label is altered.
• Variables that have labels pointing to indirect variables (which use pointers) have their label traversed so the correct base address can be retrieved, which makes the variable description accurate and validation for watching for base address accesses.
• Like with variables that use symbols, variables that use labels or are labeled do not participate in narrow searches because that will not preserve the address formulas properly for those kinds of variables.
• Cycles are not prevented and cycle detection isn't present (except in cases where it's needed like in variable annotations). The current goal is to prevent crashes. Preventing cycles in all relevant state changes cases can be difficult/tedious. If one is clever they can make a cycle that causes a variable address to always update. An example of a cycle is A -> A, or A -> B and B -> A. [edit]: we have some prevention now for cycles in 8aaa9f0