Allow component paths to be defined in a file rather than on the YAML

[rohan-at-sentry]

Is your feature request related to a problem? Please describe.
Enterprise grade companies typically have a large no. of components with a large no. of files per component. This can get really un-wieldy to maintain manually, so some companies depend on an external source of truth (like a codeowners file) to keep track of team assignments (which manifest as components on Codecov, with defined file paths.)

Because components are defined on the YAML, and there is already an external source of truth like a codeowners file, it'd be awesome to map one to the other.

Describe the solution you'd like
The solution will have 3 pieces

1. A file for every component that contains a list of paths (owned by the customer)
   a. This will be generated by the customer and involves some scripting to pull paths from a external source of truth like codeowners
   b. This will be checked into the repo, and updated as the external source of truth changes
   c. The contents of the files can be regex or globs (consistent with what we support today) and will be new line de-limited

2. The ability to define this file on codecov.yml under the individual_components section as a new paths_source attribute (new codecov feature)

3. The ability on the Codecov side to parse this file and resolve those as paths for the component (new codecov feature)

Additional context

1. We should be able to support both paths_source and paths for components (although an individual component should have either one or the other)

Here's what the YAML could look like

# ... previous config options...

comment:
  layout: "header, diff, flags, components"  # show component info in the PR comment
  
component_management:
  default_rules:  # default rules that will be inherited by all components
    statuses:
      - type: project # in this case every component that doens't have a status defined will have a project type one
        target: auto
        branches:
          - "!main"
  individual_components:
    - component_id: module_emotions  # this is an identifier that should not be changed
      name: emotions  # this is a display name, and can be changed freely
      paths_source: /some_path/.../module_emotions_paths.txt
    - component_id: module_fruits
      name: fruits
      paths_source: /some_path/.../module_fruits_paths.txt
    - component_id: module_core
      name: core
      paths_source: /some_path/.../module_core_paths.txt*
      statuses:           # the core component has its own statuses
        - type: project
          target: auto
        - type: patch
    - component_id: ascii
      paths:
        - .*/ascii.py
    - component_id: emoji
      paths:
        - .*/emoji.py

[giovanni-guidini]

Series of random questions:

• If both are present what should happen?

We should be able to support both paths_source and paths for components (although an individual component should have either one or the other)

• If we can't find the file being pointed to by paths_source do we say it's a YAML error? (This assumes we try to pull it when parsing the YAML, I guess that makes sense)

• The way the paths_source is formatted in the example it is a list. Do we really expect multiple files? It makes more sense to be a string.

[rohan-at-sentry]

If both are present what should happen?

We should raise an error (is it a YAML error during report upload? Or something else? Open to input here)

If we can't find the file being pointed to by paths_source do we say it's a YAML error? (This assumes we try to pull it when parsing the YAML, I guess that makes sense)

Yes. Additionally, if we encounter a parsing error when we try to parse the file, this would also be a YAML error

The way the paths_source is formatted in the example it is a list. Do we really expect multiple files? It makes more sense to be a string.

Good catch. I've updated the example lmk if it makes sense. You're right, we expect only single file per component definition.