[api-extractor] API reports drop #private member which should be included as it impacts type checking

[CraigMacomber]

Summary

Generating an api report for a class with a JS private member omits that member.
Including such a member impacts type checking (prevents assignment on objects that are not instances of the class to values constrained to that classes type).
Due to this, the presence of such a member is included in the d.ts file and is part of the public API for a class, however is omitted in the generated API report.
This results in changes to the API like done in microsoft/FluidFramework#21351 (adding a private field for the sole purpose of impacting type checking) having no impact on the API reports:

Repro steps

Declare a class like:

export class Foo {
    readonly #x!: unknown;
}

The field gets compiled into just #private; in the d.ts file.

Generate an API report for it.

Expected result: API report includes #private; like the d.ts file.

Actual result: API report is unimpacted by the private field.

Details

The TypeScript compile renames the field captures the fact that there are private fields with a single #private; marker, at least in 5.4.5.
Making APi extractor replicate this pattern, and include that marker if there is any JS private field might be a robust way to do this.

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/api-extractor version?	@microsoft/api-extractor@7.45.1 (with a patch, see https://github.com/microsoft/FluidFramework/blob/main/patches/%40microsoft__api-extractor%407.45.1.patch )
Operating system?	Linux
API Extractor scenario?	reporting (.api.md)
Would you consider contributing a PR?	No
TypeScript compiler version?	5.4.5
Node.js version (node -v)?	v18.17.1