Update result file schema and add demo pipeline

[hoangtungdinh]

Description

This PR is ready for CCB's review.

This PR updates the result file schema, taking into account all the requirements. All related C++ classes are also updated to reflect the new schema.

This PR also adds a docker-based demo pipeline that supports the checker bundles for OpenDrive and OpenScenario.

Main changes

1. Update the result file schema and the corresponding C++ classes. The new result file schema addresses all the requirements and is expected to be stable.
   • Remove RoadLocation references #71
   • Add rule uid to result xsd #72
   • Add rule to issue #78
   • Add checker status to represent execution status #79
   • Support domain specific info in the result xsd schema #81
2. Update the text report module to report the list of addressed rules and violated rules from the result files.
   • Add violated and checked rule list in text report #80
3. Add the demo pipeline. The demo pipeline is available on the GitHub Container Registry and will be updated every night at 4 am UTC.
   • Add demo pipeline #82
   • Add multi stage build for demo_pipeline #84
   • Add nightly build action of demo pipeline #85
   • Improve few details of the demo pipeline #88
4. Some minor improvements
   • Add precommit config yaml file #75
   • Add 4 spaces default indent to xsd files #76
   • Add linux bare build action #77
   • Fix branch name in workflow #87

How was the PR tested?

1. Tests are documented in each PR above.

Notes
This PR closes the following issues

• Remove domain specific RoadLocation issue type from framework #9
• Report list of addressed rules from result file #26
• Improve check results with information about addressed rules and meta data #25
• Setup checker pipeline on GitHub for users of ASAM standards #37
• Detect skipped or not run Checkers  #45 (to discuss)

[pmai]

Overall the changes look good to me.

The minor point I'm raising on the XML/Schema front is for architectural discussion: We should likely tighten down the schema quite a bit more, and be careful about the semantics of attribute values: Usually you want to distinguish a missing value from an empty string/value. But again this is for future direction and PRs, I think.

[pmai]

Should a non-exisiting ruleUID not be handled via eliding the attribute rather than supplying an empty string?

More generally I think going forward the schema should be tightened down to specify required attributes (currently all are optional) and more specific types for the attributes, where useful (which would e.g. disallow empty strings in places where IDs are required). This is less of a comment on the current PR, but again more for the forward-looking architectural discussions.

[pmai]

@AsamDiegoSanchez @hoangtungdinh same here: was this officially approved in the CCB? Then we should tag as ready for merge, and I can perform the merge.

[AsamDiegoSanchez]

yes, it was approved without any further comments