Configurable handling of 'manually created' Users/Groups in IAM Identity Center

**Is your feature request related to a problem? Please describe.**
Normal behavior for a uni-directional identity replication is that the downstream IdP, will contain only the user/groups (or a sub-set there of) that exist in the upstream IdP.

With IAM Identity Center, local users (those that do not exist in the upstream IdP) can exist but will not be able to authenticate (since the upstream SAML IdP can not create a auth token for a user identity it doesn't have).

AWS Control Tower's behavior of creating groups (at LZ setup time) and users (as part of account factory provisioning), also its assigning of Administrator Access. Is often found to be inconsistent with organizations Identity Management principles and the permissions granted excessive for the principle of least privilege. This behavior also only implemented when using the Identity Store with IAM Identity Center, where an instance of AWS Managed Microsoft AD or AWS Directory Service, these users are not created.

**Describe the solution you'd like**
Some users may wishes to handle locally created users and groups in a specific fashion (related issues: [#141](https://github.com/awslabs/ssosync/issues/141), [#88](https://github.com/awslabs/ssosync/issues/88), [#59](https://github.com/awslabs/ssosync/issues/59):
- **delete** (default and current behavior)
- Groups are deleted
- Users are deleted
- **disable**
- Groups are ignored
- Users are disabled
- **ignore**
- Groups are ignored
- Users are ignored

The above behavior should be configurable, via either cli parameter or environment variable (lambda)

**Describe alternatives you've considered**
- A list of Groups/User named to ignore
- likely to differ between customer environments,
- changes in service behavior (AWS Control Tower for example) may cause issues
- regex based
- more configurable than above, but has many of the same limitations

**Additional context**
'Manual' as a creation method is an implicit property and can not be directly interrogated via the apis, for this reason it would be necessary to start using the externalId field (see related enhancement [Ensure all groups/user creates in IAM Identity Store are via SCIM api and populate externalId field #166](https://github.com/awslabs/ssosync/issues/166)) to allow the code to determine what resources are SCIM provision but no longer exist upstream vs manually created resources that only exist in IAM Identity Center.

No files or tests are named. Start by reviewing related issues #141, #88, #59, and #166, then inspect the existing CLI and Lambda configuration and how externalId is handled. Done means configurable delete, disable, or ignore behavior for manually created users and groups.

Written by the indexing model from the issue text.