Introduce constants to simplify configuring output

[Garados007]

Right now RunTests contains two parameter enableTAP and enableJU which selects which output should be generated. Introducing a single output parameter which replaces enableTAP and enableJU can simplify the configuration and future extensions. It is only necessary to add more constants, which is easier than introducing new parameter. This can also simplify some internal code paths and function calls.

Right now I can think of the following constants:

• UTF_OUTPUT_NONE - no output, only to history
• UTF_OUTPUT_JUNIT4 - JUnit 4 implementation (#334)
• UTF_OUTPUT_JUNIT4_BAMBOO - our current JUnit implementation
• UTF_OUTPUT_JUNIT5 = UTF_OUTPUT_OPEN_TEST - JUnit 5 (#335)
• UTF_OUTPUT_TAP13 - our current TAP implementation
• UTF_OUTPUT_TAP14 - TAP 14, there are only few differences
• UTF_OUTPUT_HTML - our Html tracing output, only used if tracing activated
• UTF_OUTPUT_COBERTURA - cobertura output (#206), only used if tracing activated
• UTF_OUTPUT_DEFAULT = UTF_OUTPUT_NONE | UTF_OUTPUT_HTML - the default if output is not set

Usage example:

    RunTests("Proc0", output = UTF_OUTPUT_JUNIT4 | UTF_OUTPUT_COBERTURA | UTF_OUTPUT_TAP14, traceWinList = "Proc0")

[Garados007]

This will remove the HTMLCREATION setting for traceOptions in RunTests.

[Garados007]

We can also remove the fixLogName parameter and introduce a UTF_OUTPUT_FIXED_NAME constant. This makes it easier to transport the information to the necessary places and configuring this.

[t-b]

We could do that yes. But I'd like to retain compatibility with earlier versions, so the existing parameters would need to stay. But also translating them to the new approach would make the code nicer I guess.

[Garados007]

During this we will collect more an more "Altlasten" (legacy code which is only used to keep support with old versions) which makes our public API cluttered. At one point we need to make a major release which removes a big parts of it. I don't know when the time is come but we have to keep this in mind. Creating an issue to keep track could be maybe a good idea.

[t-b]

At one point we need to make a major release which removes a big parts of it.

We do have https://github.com/byte-physics/igor-unit-testing-framework/issues/13 to track these breaking changes.

I'm all for removing legacy code, but it involves quite an effort to upgrade on our side.