chore: change junit inline namespace to normal namespace

[HansRobo]

Description

Abstract

Change the junit inline namespace to a normal namespace to avoid common::Error being ambiguous.

Background

There are two Error classes in common namespace.

• common::junit::Error
• common::scenario_simulator_exception::Error

But, the both of second level namespace, junit and scenario_simulator_exception are inline namespace.
Therefore, common::Error is a valid expression for both of Error classes, and in an environment where both are valid, it will cause the following compilation error:

 error: reference to ‘Error’ is ambiguous
  |     throw common::Error(

Details

Mostly, common::Error means common::scenario_simulator_exception::Error.
Therefore, I modified common::Error to mean only common::scenario_simulator_exception::Error.

References

RegressionTest: WIP

Destructive Changes

If external code that uses common::Error for common::junit::Error is present, it will occur compilation error.
Note: This is a possibility, and as far as I know, such a code has never actually existed.

Known Limitations

None

[github-actions]

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

• Is this pull request written in a way that is easy to read from a third-party perspective?
• Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
• If this pull request contains a destructive change, does this pull request contain the migration guide?
• Labels of this pull request are valid?
• All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
• The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.

[HansRobo]

Since I have found that this name collision was intentional by the author ( @yamacir-kit ) , I am closing this PR.
The author's current position is that the full name of the Error class should basically be used, and that it is only possible to omit it when the intermediate namespace can be omitted.
Therefore, in an environment with mixed definitions, where an error occurs stating that common::Error is ambiguous, the abbreviated name common::Error is likely to confuse not only compilers but also humans, so it is better to use the full name and make it clear which Error class it is.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
66.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud