Set up a scheduled job that runs ORT on ORT

[sschuberth]

For the sake of "eating our own dog food" and to showcase how ORT performs on a rather big / complex project like ORT itself, we should run ORT on ORT regularly. This would also get us any compliance documents / artifacts that are eventually needed for distributing ORT as a Docker image.

Several contributors have already worked on this topic on and off, and there is an .ort.yml file for ORT, but there are more problems to solve , probably mostly in tests assets (some of which are deliberately broken). So we should get this straight once, and then ensure "dogfeeding" ORT to ORT works on a regular basis.

[nicorikken]

Bootstrapping dependency order discussed on the 25th of August:

1. Containerized ORT version for the ORT scanning Action
2. ORT scanning GitHub Action
3. Integration of the ORT scanning Action in the ORT GitHub Actions pipeline
4. Speed up scans using caching to prevent time-out
5. Provide curations and fix issues to make it not fail

Going by the experiences discussed ORT currently requires quite some curations and still there remain Gradle errors.

The caching is likely to be necessary as the scan would otherwise take too long and would time-out. So some (public) caching method is needed to speed things up.

[sschuberth]

The caching is likely to be necessary as the scan would otherwise take too long and would time-out. So some (public) caching method is needed to speed things up.

Correct. Ideas that were discussed include using ClearlyDefined as a global scan storage (required fixing of #4540) or implementing a new scan storage based on IPFS (see #1328).