SnippetChoices: Data model improvements

[fviernau]

Scenario

The snippet choices refer to file path in the source tree of a project.
These paths, given.source_location.path are relative to provenance, while the rest of ort.yml
uses paths relative to the analysisRoot. Interrestingly, the provenance property is not even used for matching snippets, at least no in scanoss.

Problem:

• Dealing with two types of paths, relative to provenance and relative to analysis root can be confusing for the
  user.
• If the code was "fixed" to adhere to provenance when matching, this may run into issues related
  to different ways of cloning, e.g. via https vs. ssh, or sometimes even cloning from a mirror. Also
  less relevant edge cases like moving a repository or forking, the license choices need adjustments.
• There seems to be no benefit in specifying provenance + relative path compared to just specifying
  pathRelativeToAnalysisRoot.

Example

snippet_choices:
- provenance:
    url: "https://github.com/vdurmont/semver4j.git"
  choices:
  - given:
      source_location:
        path: ".github/workflows/ci.yml"
        start_line: 3
        end_line: 17
    choice:
      purl: "pkg:github/RS2007/dotfiles@0384a21038fd2e5befb429d0ca52384172607a6d"
      reason: "ORIGINAL_FINDING"
      comment: "Explain why this snippet choice was made"

Goal

• Drop Choices.Provenance
• Make sourceLocation relative to analysisRoot (so that all file paths in ort.yml are consitently relative to analysis root)

Drawback / complications

• If provenance is included twice in same revision, snippet choices have to be made in both locations.
• However, as the snippet scanner (scanoss) is run per provenance, this has a slight design mis-match
  and seems to be tricky to imlement: If a file has multiple checkout paths, then
  the choices for that single path may differ. In such case, the application of choices may
  be changed to 1. either ignore inconsistent choces or 2. apply snippet choices only after
  receiving data from the backend.

Note: The path patterns of PathExcludes also had been interpreted as being relative to provenance, which was wrong and is fixed here.