REUSE software integration

ClearlyDefined could probably benefit from a native integration of FSFE's [REUSE software](https://reuse.software/), especially for Git-based sources. The files of repositories that are fully compliant with the REUSE specification, i.e. define a proper license and copyright attributions, are currently not automatically detected by ClearlyDefined in many cases, but their authors have already made the effort to _clearly define_ proper license and copyright information.

Example: https://github.com/SAP/styleguides
The [dep5 file](https://github.com/SAP/styleguides/blob/main/.reuse/dep5) specifies a wild card for all files in the repository. ClearlyDefined however only [detects the license of the LICENSE file itself](https://clearlydefined.io/definitions/git/github/sap/styleguides/9b1c3142c610c28cdfaf74ed4383c65e7c8db8da). As it's properly registered with the REUSE service, a simple [call to the REUSE API](https://api.reuse.software/status/github.com/SAP/styleguides) could do the job for the remaining files. If there are non-compliant files, the API also returns this information.

As [there are several possibilities to be compliant with REUSE](https://reuse.software/spec/), their tool should probably be used to check the repositories (instead of an own parser) - either by using their API or by executing their tool locally. I'm personally willing to engage in the integration efforts, I probably only need some hints where it would fit best and what you would prefer from an architecture perspective (API call or native tool integration). Of course, please also let me know your thoughts on the idea... :)

Benefits:
- Much better detection rates for license and copyright attributions
- Less follow-up work for curation
- Higher motivation for projects to adopt REUSE

Potential challenges:
- The REUSE Service only scans the latest commit to a Git repository, ClearlyDefined accepts an arbitrary commit hash that doesn't need to be the latest one. However, this might be acceptable as REUSE could simply be ignored if a harvest is triggered for an older commit or for a certain release. On the other side, it could be mitigated if the REUSE tool is run locally - the REUSE API wouldn't be called then.
- Additional complexity/error sources as another data source is added