[Feature] Ability to Identify Telemetry Items by Micro Frontend Source

Hi Team,

In micro frontend (MFE) architectures, several independently deployed MFEs can operate on a single host page. Currently, the @microsoft/applicationinsights-web SDK doesn’t offer a straightforward way to determine which telemetry item comes from which MFE when multiple MFEs use the same Application Insights instance.

**Problem**
1. Telemetry from all MFEs (such as page views, dependencies, custom events, exceptions) is grouped under the same “app,” making it hard to distinguish between sources.
2. This complicates filtering, analysis, and correlation of telemetry for each MFE in Azure Application Insights.
3. Currently, custom telemetry initializers must be added to each MFE to include properties like `cloudRoleName` or `microFrontendName`, which can lead to inconsistencies.

**Proposal**
Add native SDK support for identifying telemetry items by their micro frontend source.

**Potential solutions include:**
1. Letting each MFE configure a `cloudRoleName` or `componentName` during SDK setup, applied to all telemetry from that instance.
2. Ensuring the `microFrontendName` is included in the telemetry envelope for filtering.
3. Allowing auto-collected telemetry (page views, dependencies, AJAX calls) to inherit the `microFrontendName`.

**Benefits**
- Easier separation of telemetry for each MFE.
- Simplifies debugging, filtering, and monitoring of MFEs.
- Reduces the need for custom telemetry initializers.

**Example Use Case**
- A large eCommerce site has MFEs for search, cart, checkout, and profile, all using App Insights SDK on the same page.
- Currently, all telemetry is grouped together.
- Ideally, telemetry from each MFE would be tagged with its name for better isolation of performance and errors.

Looking forward to your feedback on this request.

Start by reviewing SDK setup, telemetry initializers, auto-collected telemetry, and telemetry envelope behavior described in the issue. Resolve whether configuration should use cloudRoleName, componentName, or microFrontendName, then define coverage for page views, dependencies, AJAX calls, custom events, and exceptions as the done criteria.

Written by the indexing model from the issue text.