Add generic configuration file support

[rsenden]

Enhancement Request

There have been several discussions on having a Fortify-specific configuration directory, somewhat similar to .github that can hold CI or Copilot configuration. This configuration directory could be used by various Fortify products, like fcli, sourceanalyzer, IDE plugins, ..., to define for example (default) scan settings. This ER describes some ideas on this topic.

Some ideas/considerations:

• Name and location of (default) configuration file(s), like <current dir>/.fortify/config.yml, ~/.fortify/config.yml, and /etc/fortify/config.yml
• Do we have a single configuration file for all tools (config.yml), or separate files for specific tools (fcli.yml) and/or specific use cases (sast-scan.yml)? Single config file likely generates a more unified Fortify product user experience.
• Can a single configuration file hold multiple profiles, for example different configurations for sast-scan vs dast-scan?
• Ability to use a configuration file in a non-default location, for example through command-line option
• How to handle non-static values, like branch name, commit id, ...? For example to base default application version name on Git branch name.
• Ability to 'include' shared configurations from URLs?
• Current fcli ci action (and GitLab/GitHub integrations) are heavily based on environment variables for configuration, repository-based configuration files could potentially simplify some of this configuration, especially for the various *_EXTRA_OPTS environment variables

To implement some of the above, products like fcli could look for/merge configuration data from the current dir/user dir/system-wide dir, with the option to override or merge with a custom config file, and/or for selecting a specific profile like sast-scan.

Assuming a single configuration file shared by all products, we might have top-level sections that are supported by multiple products, but to start with, we could use the product name as the top-level property (within each profile?), to allow each product to define its own configuration structure, ignoring any other top-level properties. For example:

include:
  - https://some/shared/config
profiles:
  default:
    sourceanalyzer:
      <sourceanalyzer-specific configuration structure>

    fcli:
      ssc.appversion.create:
        name: <reference to git repo name>:<reference to git branch name> # TODO: How to represent this?
        issue-template: Prioritized High Risk Issue Template
      # TODO How to represent things like PACKAGE_EXTRA_OPTS
      # TODO In addition to option defaults, maybe also allow for configuring env-var values, system properties, ...?

  sast-scan:
    extends: default
    fcli:
      ...

  dast-scan: 
    ... 

Fcli already utilizes a default option value provider that looks for FCLI_DEFAULT_* environment variables; it shouldn't be too difficult to extend this functionality to also support reading default option values from configuration files. This would automatically support configuration of all fcli command options, we'd likely want to extend this to fcli action options.