Add namespaces and optional writer config

[vloncar]

Description

As observed in the emulator in CMSSW, there are some issues with global namespace being polluted when multiple versions of the same model are loaded. The accepted solution was to use namespaces. This PR follows up in hls4ml by adding the ability to generate namespace and optionally not write .txt files (also requested by the emulator people) and not to write .tar.gz (everyone hates this). The new configurable options are placed under WriterConfig as it made no sense to shove them under HLSConfig. In the future with the new config scheme we will re-evaluate this.

Type of change

• Documentation update
• New feature (non-breaking change which adds functionality)

Tests

There's a test in test_writer_config.py for the 3 new config options

Checklist

• I have read the guidelines for contributing.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have installed and run pre-commit on the files I edited or added.
• I have added tests that prove my fix is effective or that my feature works.

[jmduarte]

After discussing this with @thesps @aloeliger, we realized that the definition of nnet_utils may also collide (to be checked), which we want to prevent in principle due to potential differences in hls4ml versions, etc., so I think we should also try to protect those in this PR

[thesps]

Could we also protect the nnet_utils function definitions? They are currently all in the namespace nnet, but we want to allow that each model/project can use a different hls4ml version/implementation, so it would be good to change that to the same namespace that applies to the weights.

[vloncar]

It would be better if we worked on understanding the root of the problem rather than patching up in anticipation of unexpected behavior. Making the nnet_utils part of the namespace won't solve the issue if function loading is the problem, as the interface fundamentally depends on the existence of create_model and destroy_model functions in every loaded library and you can't put those in namesepaces. We have not seen this failing which is expected behavior according to the standard. We have also not seen bad casts which suggests types don't clash. We have only seen this in initialization of static arrays. I was unable to reproduce this and create a MWE, making me think CMSSW environment is more specific and we should understand what goes on there better. Or we just forget about all of this emulator business and go back to the solution of pasting the code of all models in CMSSW codebase if we want to be safe.