ClickAnalyticsPlugin: native <input> click capture silently gated by hardcoded clickCaptureInputTypes, independent of trackElementTypes

`AutoCaptureHandler.ts` applies **two independent filters** before capturing a click on a native `` element:

1. The element's `tagName` must be in `_clickCaptureElements` (derived from the configurable `trackElementTypes` option, default `a,button,area,input`).

2. If the tag name is `INPUT`, the element's `type` attribute must **also** match a second, hardcoded, non-configurable allowlist:

```ts

const clickCaptureInputTypes = { BUTTON: true, CHECKBOX: true, RADIO: true, RESET: true, SUBMIT: true };

...

var sendEvent = tagNameUpperCased === "INPUT"

? clickCaptureInputTypes[element.type.toUpperCase()]

: true;

```

This means any `` with `type="text"`, `type="number"`, `type="email"`, `type="search"`, or no `type` attribute at all (e.g., PrimeNG's `pInputText`/`p-inputnumber` output) is **silently excluded** from click capture, even though:

- `"input"` is present (by default) in `trackElementTypes`, and

- Nothing in the [README](https://github.com/microsoft/ApplicationInsights-JS/tree/main/extensions/applicationinsights-clickanalytics-js#readme) or `IClickAnalyticsConfiguration`/`Datamodel.ts` docs mentions this second, independent restriction.

This is easy to confuse with `_clickCaptureElements`/`trackElementTypes` (which *is* documented and configurable) since both allowlists happen to include the token `BUTTON`. Users debugging "why don't my text field clicks show up in `customEvents`" have no way to discover this behavior short of reading the plugin's source.

Related but distinct: #2136 addressed making the **tag-name** list (`trackElementTypes`) configurable; it did not touch this **input-type** allowlist.

### Describe the solution you'd like

- Document `clickCaptureInputTypes` and its behavior in the README/config docs, explicitly noting that `trackElementTypes` including `"input"` does **not** guarantee all `` clicks are captured. If this is an issue of possibly exposing user inputted data, it would be nice to call that out.

Ideally:

- Expose `clickCaptureInputTypes` as a configuration option (similar to how `trackElementTypes` was made configurable for #2136), so consumers can opt in to capturing clicks on text/number/search inputs if they've assessed the PII/data-sensitivity tradeoffs for their own app.

---

Start with extensions/applicationinsights-clickanalytics-js/src/AutoCaptureHandler.ts and trace the clickCaptureInputTypes check alongside _clickCaptureElements. Read the README, IClickAnalyticsConfiguration, and Datamodel.ts documentation, using #2136 for context on trackElementTypes. Done means the input-type behavior is documented and, if the configuration change is accepted, its option and data-sensitivity implications are covered by the relevant tests and docs.

Written by the indexing model from the issue text.