target language toplevel namespaces should be robust

[bozzzzo]

This time around it was further aggravated by having quarkc and generated code use the same virtualenv, so the effect was even more dramatic. Moving quark out to a separate virtualenv would help quark, but not help the user of generated quark code.

a quark test file had namespace org which caused jinja that is imported by the compiler to indirectly import quark runtime, which reconfigures logging only if QUARK_TRACE=1 environment variable is set.

End effect was that QUARK_TRACE=1 quark run --java foo.q produced different output which failed the quarkc/test/test_env_tracing.py

The solution depends on target language.
Where namespaces can be merged (java, ruby) an additional toplevel namespace quark sounds like the right approach
Where namespaces cannot be merged (python, js?) the toplevel namespace should be prefixed with `quark_' to separate them from other toplevel namespaces.