Control color output with C2_COLORS environment variable

[chqrlie]

• use style names instead of hard-coded color names
• customize color output via environment variable C2_COLORS: eg: C2_COLORS=none, C2_COLORS="error:bright-blue, C2_COLORS="error:#d0d0d0
• use cache to multiple calls to unix.isatty() and stdib.getenv()
• simplify error formating in source_mgr.c2

[bvdberg]

Please be Very careful with globals in combination with plugins. Since the plugins will have a different set of them. Please see the ast.setGlobals() function. It's a bit of a hack, but it's the only way to have access to the same globals atm..

[chqrlie]

Please be Very careful with globals in combination with plugins. Since the plugins will have a different set of them. Please see the ast.setGlobals() function. It's a bit of a hack, but it's the only way to have access to the same globals atm..

Yes, I am aware of this problem. As long as we call color.useColor() in both c2c and in all plugins, the global color variables should be initialized and cached with the same values.

Alternately, we could make these variables members of the diagnostics or globals or another appropriate structure to ensure encapsulation and dynamic sharing with the plugins.

The globals variable in ast/utils.c2 is definitely a hack.

[bvdberg]

To keep the plugins working, all AST globals need to be moved to the Globals struct)