Add cubescript-defined variables.

[shacknetisp]

This PR adds cubescript-defined variables to replace faux-variable aliases.

There are three commands and one alias added and described in usage.cfg:

// Integers
defintvar <name> <min> <current/default> <max> [<flags>] [<on_change>]
// Floats
deffloatvar <name> <min> <current/default> <max> [<flags>] [<on_change>]
// Strings
defstringvar <name> <current/default> [<flags>] [<on_change>]
// Booleans (integer from 0 to 1)
defboolvar <name> <current/default> [<flags>] [<on_change>]

on_change is CubeScript that will be executed when the variable is changed.

This also adds variables for the IDF_* flags that are useful and allowed for cubescript-defined variables:

$idfbithex
$idfbitpersist // especially useful
$idfbitreadonly
$idfbittexture

Under the hood, this adds additional functionality to idents so that they may store cubescript to be executed on change.
I am working within the existing system here, so there is a bit of hackishness especially for allowing on_change callbacks, but I think that giving cubescript proper variable support now is more useful than revamping the entire cubescript engine.

I have converted the new faux-variable aliases to variables.

[MoonPadUSer]

I'd like it if tbhey were called defint deffloat and devstring

[MoonPadUSer]

Ok, so in summary what I would like to change is:
defvar to defint
deffvar to deffloat
defsvar to defstring
idfbitpersist, etc to IDF_PERSIST (since IDF stands for identifier flag)
maybe you could even add defbool which has min val 0 and max val 1 by default

[shacknetisp]

I chose these names to be consistent with the current CS name convention, e.g. getfvarmax, getsvardef, and $mutsbitffa. Maintaining the current convention is important, we'd have to change the entire naming system for variables types and bit field flags to be consistent with the new naming.

defbool or perhaps defbvar could be defined in cubescript: defbool = [ defvar $arg1 0 $arg2 1 $arg3 $arg4 ]

[MoonPadUSer]

hum, ok I see. then please add defbvar and we're done here.

[shacknetisp]

Added defbvar. This will still need a c++ style review before merging, to confirm my implementation is acceptable.

[MoonPadUSer]

eh, I guess the case isn't really important in debug messages

[TheAssassin]

I only performed a functional and semantic review of the changes, focusing on the C++ code. Will happily re-review once my questions are answered.

[TheAssassin]

This cries "potential memory leak" all over the place. I'll have to look into ident resp. addident to see whether this is ever cleaned up.

[shacknetisp]

These never get deleted; C++ variables use global variables as storage. Variables exist forever.