Switch back to holding Colors in StaticLightingArrayIntent.cs
On my system with Giz's Canon the array usage dropped from 114 MB (14k obj) to 91 MB (15k obj).
Changed the StaticLightingArrayIntent to use a 'long' argb value as its data store.  I didn'r realize how big a Color was.  This takes the Nutcracker memory in Giz's Canon down to 25 MB (from 91 MB when using Color (which was down from 114 MB when using LightingValues).  I'm a little worried that something has been lost here, but I can't see it.
Changed the StaticLightingArrayIntent to use an 'int' argb value as its data store.  I didn'r realize how big a Color was.  This takes the Nutcracker memory in Giz's Canon down to 25 MB (from 91 MB when using Color (which was down from 114 MB when using LightingValues).  I'm a little worried that something has been lost here, but I can't see it.
Additional memory optimizations...
Rework calculation to be more performant.
Drop intents that have no intensity. Discrete colors that where not used in a effect still generated intents of 0 value.
Trim extra attributes the are not necessary and make their constant fields static.
Remove debugging code.
Fix a bug that was redrawing the standard Lighting values multiple times.
Merge branch 'colors' of https://github.com/billlutton/vixen into colors
Merge remote-tracking branch 'remotes/giz/colors' into colors
Performance and Sanity Checks
Change the Combiner to use an int for a key vs a random string... Saved 12MB in memory usage..
Merge remote-tracking branch 'remotes/giz/colors' into colors
Merge remote-tracking branch 'remotes/giz/colors' into mergeall1
Merge remote-tracking branch 'remotes/derek/Sequencer_UI' into mergeall1
Merge branch 'colors' into mergeall1
Merge remote-tracking branch 'remotes/giz/master' into mergeall1
This change turns LightingValue back into a struct.  It also removes the other null checks that were needed because some intent states return 'default(valType)' when asked for stuff they don't have (like a time point they don't have).  This change does nothing for the underlying problem that there doesn't seem to be universal agreement on the nature of and effect/intent's timespan being open/closed on one end or another.

On the bright side, we know that turning lightingValue into a class can be used to expose these cases.
- Memory freeing in the sequencer