feat: allow configuration of the vite HMR server

[RGunning]

Vite allows additional configuration options for the HMR server that let the user set the port, protocol and host etc. of the HMR server.

Configuring HMR server to run on a different port to the main application fixes the issue

PR Checklist

Please check to confirm your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Currently it is impossible to configure the vite HMR server as this configuration option is not made available.

There is a bug in vite/browserstack which currently prevents running a local application using browserstack as the page will reload every ~50 seconds due to the websocket connection being lost. For some reason this only occurs when the application and the HMR are being served on the same port, resulting in the following error being thrown client:529 WebSocket connection to 'ws://localhost:4200/' failed: Unrecognized frame opcode: 5. On receiving this error vite triggers a reload https://github.com/vitejs/vite/blob/eb08f605ddadef99a5d68f55de143e3e47c91618/packages/vite/src/client/client.ts#L106-L108

Issue Number: N/A

What is the new behavior?

It is now possible to configure the hmr configuration in the angular.json making it possible to configure more advanced hmr settings (https://vitejs.dev/config/server-options.html#server-hmr).

A use case of this is that it allows a custom hmr config which bypasses the browserstack error seen above.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information