Ane 873 - support --policy-id

[csasarak]

Overview

This PR makes it so that the CLI can accept a new policy id argument as part of require policy work.

This will likely merge after #1202 because removing wiggins will simplify this PR.

Acceptance criteria

• Should be able to set a policy id with --policy-id <num> or using the policyId: <id> directive in .fossa.yml.
• Only one of a policy name or policy id can be set. This rule applies to mixed CLI and config file arguments also.

Testing plan

1. Set the require policy flag for an organization.
2. Scan a project, making sure to add --project <name> with a name that has never been used before. A previously deleted project does not behave as a new project on this endpoint. ANE-462 is meant to address this. It should fail with an error about a missing policy.
3. Run fossa analyze with the --policy-id <number> with the id of a policy. You can get this by navigating to the policy's page in the web UI and looking at the URL. It should succeed.

Run fossa analyze --policy name --policy-id 1, it should fail. Likewise if you put both or one of the directives in .fossa.yml.

Risks

References

ANE-873
Core PR to support policy-id: https://github.com/fossas/FOSSA/pull/10171

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).

[jssblck]

Please document the exact semantics, since these are both marked "mutually excludes".

Reading the code, I believe that if both are provided, policy takes precedence.
If this is correct, please clearly document everywhere we document these flags/settings.

I recommend using wording similar to:

#### `project.policy:`
The name of the policy in your FOSSA organization with which to associate this project. 

If this option and `project.policyId` are both provided, 
this option takes precedence and causes `project.policyId` to be ignored.

#### `project.policyId:`
The id of the policy in your FOSSA organization with which to associate this project. 

If this option and `project.policy` are both provided, 
`project.policy` takes precedence and causes this option to be ignored.

[jssblck]

[optional] I think it'd also be helpful to tell users how to get the ID of a given policy.

If we don't have existing Core-side docs to point them to for this, please consider writing a quick doc in docs.fossa.com to link to.

[csasarak]

I've added a note here about how the CLI variants of these values take precedence over config file ones. From our other discussion here I think that mutually excludes is the right language otherwise.

I will look into making a doc tomorrow on where to get a policy id, right now the main way I know of to get them is from the URL of the policy page.