Support bring-you-own-function projects for swa start

**Is your feature request related to a problem? Please describe.**
To develop static web apps with functions that take advantage of managed identity it is necessary to deploy the functions to an functions-app separate to the swa-app and then link them together. This is referred to in the documentation as Bring Your Own Functions.

A solution which makes use of Bring Your Own Functions will often use two git repositories to store the SWA and the function-app sources.

With remote development approaches such as codespaces or docker containers becoming more common, it is likely that the developer will find themselves running/debugging the SWA and the function-app on different network hosts. They may also deploy the function-app to Azure and want to run/debug their SWA app locally.

When the function-app is running on a different network host to the swa-cli, the developer will need to specify the URL to the function-app as an HTTPS URL. Currently the swa-cli does not support this use case, but can be made to do so with a few changes.

**Describe the solution you'd like**

Support proxying of API requests to APIs hosted on remote hosts, using HTTPS URLs.

Allow use of insecure connections to the remote API similar to the `-k | --insecure` command line option in curl. This is to handle the case where the API host is using wildcard certificates which do not appear to be accepted by the http-proxy node module used by swa-cli.

When proxying requests to the remote function-app, swa-cli should rewrite the host header to match the URL of the function app. Without this the function-app host will receive a request with a Host header of /localhost/ and will respond with a 404.

**Describe alternatives you've considered**
When running the function-app in GitHub codespaces, port 7071 can be shared publicly. I tried making this available over HTTP, but this does not appear to supported for public ports.

VS Code will forward ports in codespaces to the local development host. I then tried using ngrok to make the local port available at a public HTTP URL which could be accessed by the swa-cli running in another codespace, but ran into connection issues around wildcard TLS certs used by ngrok.

**Additional context**
Setting a remote URL with the `--api-location option` to `swa-cli start` causes swa to attempt to resolve the URL as a filesystem directory. It is necessary to also specify the `--api-devserver-url` option.

However specifying `--api-devserver-url` only causes swa-cli to not be aware of any API server settings since conditional logic prevent `--api-devserver-url` being examined if `--api-location` is not also specified. Therefore in testing (of updates to swa-cli) I had to use command lines similar to:
```
node dist/cli/bin.js start http://localhost:3000 --api-location dummy --api-devserver-url https://codespaceshost-7071.githubpreview.dev
```

**Changes needed to support this use case**
- [X] `net.ts` `parseUrl` function should return port 443 for HTTPS URLs. Currently it returns 0 which causes a timeout in subsequent connection checking. See https://nodejs.org/dist/latest-v16.x/docs/api/url.html#urlport which explains the parsed port from a URL can be an empty string. PR #524 merged.
- [ ] ~~`msha/handlers/function.handler.ts` should optionally call `httpProxy.createProxyServer` with `{ secure: false }` to prevent connections to remote function-apps failing due to wildcard TLS certificates. Addressed in PR #534.~~ (Update 2022-10-03: No longer needed. Only the host header change, mentioned below, is necessary for TLS connections to remote API hosts)
- [ ] `msha/handlers/function.handler.ts` `injectHeaders` function should set the `host` header to match the host of the remote function-app. Without this change the `host` header will remain set to `localhost` and proxied request will likely fail to get routed corrected at the remote host. Addressed in PR #578.

With the above changes I was able to connect swa-cli to a remote function-app addressed via an HTTPS URL.