Fix bugs in name mangling

[petervdonovan]

The assignment of mangled names is too complex when compiling several distinct programs in the same JAR execution because it causes the different programs to interact with each other by changing the number of reactors that have the same name. We can patch this up (by parameterizing the uniqueName function by the current FileConfig, for example), but it is safer and easier to just eliminate the global variables. It will make the generated code uglier, but maybe life is too short to worry about that.

This PR fixes the assignment of unique names mechanism so that it does not use global variables, which could result in interactions between multiple distinct compilation processes that affect the names used in generated code. This ensures that if one compilation only uses one reactor class with a certain name, then no numbers will be appended to the reactor class's name. It also appends the concrete types used to the reactor class's name, which may be useful for debugging.

The order in which reactor classes with the same name are numbered is based on the alphabetical ordering of the string representations of their URIs. Since different reactor classes with the same name cannot appear in the same file, I believe that this should work properly.

Here are some examples of unique names produced by the method implemented in this PR:

_superlong_double_char_int_float
_modal
_modal1

[petervdonovan]

This PR includes some changes in CI that were necessary in order to make CI output more useful. I can move them into a separate PR if needed, but this is not a big PR anyway so maybe it is OK. Note that there is a commit cherry-picked between this and #1814.

[lhstrh]

This PR includes some changes in CI that were necessary in order to make CI output more useful. I can move them into a separate PR if needed, but this is not a big PR anyway so maybe it is OK. Note that there is a commit cherry-picked between this and #1814.

I'm not sure I agree those CI changes are a good idea. What motives them?

[petervdonovan]

• Currently the tests stop running when one test category fails. This prevents CI from uncovering all of the errors that it could uncover.
• Often I find that I am the only person submitting tasks to the GH actions queue. Therefore, it is in fact useful to increase the amount of parallelism in the workflow. With this change, many of the test categories which might fail complete their tests within 3 minutes.
• It is easy to find which test categories are failing by just looking at the list of jobs (on the left). Otherwise, you have to search the log, the interface to which is quite laggy.

[petervdonovan]

I realize that if we want these changes, we would need to update the "required jobs" in the repo settings, which can be done.

[petervdonovan]

The CI changes are too controversial and do not belong in this PR, so I reverted them. @lhstrh, I think we should merge this soon so that master does not continue to be broken.

[lhstrh]

This generally looks good and I agree we should merge it. Please add the missing JavaDoc and this should be ready to to go...

[lhstrh]

This file has some undocumented methods.

[lhstrh]

LGTM!

[petervdonovan]

There is something wacky happening in the Rust tests. The test framework is throwing an NPE and I am not sure why.

[petervdonovan]

OK, fixed. The problem was that there already was a test for generics, but it was called runTypeParameterTests.