We're renaming them from webvital_xxx_xxx_xxx to browser_web_vital_xxx.
This change benefits us in three ways:
1. Browser metrics will be namespaced with browser_
2. webvital is two words, so web vital
3. We're assuming that users will have the context of web vital metrics
so that we can use the abbreviations which also helps with the display
of them at the end of the test run.

Closes: #884

This type will use env to retrieve the remote ws url details and
whether one is supplied. It will store this data, which can then
be retrieved when needed.

Create a new instance of remoteRegistry which can be stored in the
RootModule. This single instance of remoteRegistry can be set in all
new ModuleInstances. Later on anything requiring the remoteRegistry
should be able to access it to retrieve the remote ws url.

Now that the remoteRegistry is part of the ModuleInstance, we can
retrieve the parsed data from the env var and use it when setting up
the mapping for the current vu.

When K6_BROWSER_WS_URL is a comma separated list of ws urls, we need
to pick from the list every time remoteRegistry.IsRemoteBrowser is
called, not just once when remoteRegistry is created. This change moves
the round robin (with the use of rand) to remoteRegistry.Is...
...RemoteBrowser from env.IsRemoteBrowser. env.IsRemoteBrowser now
only collects and returns the list of ws urls.

Env package now contains one type that is specific to the environment.
The registry package contains changes which are specific to retrieving
the remote ws urls. So this commit splits the two different concerns.
A future commit with also move the remote registry specific logic from
the browser package into the registry package.

To encapsulate the remote registry logic, we've moved the remote
registry logic from the browser package into the remote package.

We no longer need to expose the pkg scoped IsRemoteBrowser since the
only thing calling it is NewRemoteRegistry. The logic has been moved
into NewRemoteRegistry.

Resolves: #889 (comment)