Derive subject display name

**What is this about?**

Because of the nature of how subject names are displayed, across UI screens such as Permissions, approvals, we need to standardize on the name property that is to be derived from the subject. As of today, we make the assumption that subjects mainly consists of origin, which we derive hostname, which ultimately is used as the display name. Take for example a Dapp as a subject - `https:///www.google.com` would be a subject ID and `www.google.com` would be the display name. However, this pattern is not scaleable and does not apply to all cases. For example in the case of WalletConnect, the subject ID would be the channel ID whereas the display name would be the hostname of the interacting subject. Similarly, using a snap as a subject - the subject ID may be the snap ID, whereas the display name would be the snap name.

By decoupling where the subject display name is derived from, we would be able to standardize on the subject name property, which could be set by each subject. The examples below illustrate what this might look like. Note - these are just examples and may not reflect the exact changes of the task.

Subjects
- Dapp
- subject ID: `https://app.uniswap.org`
- display name: `app.uniswap.org`
- WalletConnect
- subject ID: `CHANNEL_ID`
- display name: `app.uniswap.org`
- SDK
- subject ID: `CHANNEL_ID`
- display name: `Unity Game Name`
- Snap
- subject ID: `SNAP_ID`
- display name: `Solana Snap`

**Technical Details**

- Add a display name property to `BackgroundBridge`, which is set when each subject initializes the bridge
- WC, SDK, Browser, Snap
- Ensure the same property is passed into `RPCMethodMiddleware` so the name used is consistent across flows
- Update UI to use this name property instead of `hostname`
- Due to how WalletConnect works, we may have to pass in a display name property to permission request when WC prompts an initial connection (This is because WC requests before BackgroundBridge is created)
- Remove old usage of old display name (usually instances of hostname) from UI

**Acceptance Criteria**

- Check WC, SDK, Browser, and Snaps
- UI for these flows are displaying correct display name

**Stakeholder review needed before the work gets merged**

- [ ] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

**References**

Old WIP PR - https://github.com/MetaMask/metamask-mobile/pull/13698

_No response_

Start by reviewing the existing BackgroundBridge and RPCMethodMiddleware flows, then trace how the UI currently derives names from hostname for WC, SDK, Browser, and Snaps. Compare the old WIP PR for relevant context. Done means each flow supplies and displays the correct subject display name, including WalletConnect's initial permission request, with old hostname usage removed and tests passing.

Written by the indexing model from the issue text.