[api-extractor] Add options to include forgotten exports in API report and doc model files

[zelliott]

Summary

Fixes https://github.com/microsoft/rushstack/issues/3513.

Details

• Adds apiReport.includeForgottenExports and docModel.includeForgottenExports configs to api-extractor.json that control whether forgotten exports are included in the API report and doc model files, respectively.
• Adds a new ApiExportedMixin mixin to api-extractor-model to allow API items to store whether they are exported or not from their container module (i.e. entry point or namespace). This is necessary for building the proper canonical reference (i.e. with or without a ~ navigation step). Note that this mixin doesn't actually serialize the new isExported property to the .api.json because this info is already present in the canonical reference, thus no .api.json change needed.
• Reworks CollectionEntity and the parts of the Collector that construct them to change the definitions of "consumable" and "exported" as previously defined by api-extractor. More on this below:

Consumable vs exported

Before this PR, collector entities could be exported and/or consumable. An exported entity was a top-level export, like:

/** @public */
export declare class A {}

whereas a consumable entity was either a top-level export OR an entity exported from an AstNamespaceImport. An example of the latter might be:

declare class B {}

/** @public */
export declare namespace n {
  export {
    B
  }
}

This previous definition of consumable is incomplete and misleading for a few reasons:

1. It doesn't actually care whether the AstNamespaceImport n is exported. This is a bug.
2. It only applies to AstNamespaceImport namespaces, not normal AstSymbol namespaces. There's fundamentally no reason why the two should be treated differently. This also leads to bugs.

This PR updates the definition of consumable to the following: A consumable entity is either a top-level export or an entity exported from a consumable parent namespace.

This PR also updates the definition of exported. The previous definition is not particularly useful today (almost all code paths use consumable instead of exported). Instead, we need to know whether an entity is exported with respect to its parent module, for the purposes of writing the proper navigation step in api-extractor-model. Thus, this PR updates the definition of exported to the following: An exported entity is an entity exported from its parent module.

How it was tested

I added a new test to api-extractor-scenarios and manually validated that stuff looked correct.