Implement code to establish new pattern for building services for Webview Service

[lyonsil]

From our discussions on Discord, we agreed:

• We should eliminate the use of isRenderer(), isExtensionHost(), etc. to fold all the code differences between processes into a single method.
• Client/server implementations should not be locked into sharing the same interface.
• We need good names for the client and server parts of a service. One idea was that "XYZServiceClient" could be simply "XYZService", and "XYZServiceServer" could be "XYZServiceProvider."
• We should have a clear place to put helper code shared between the client and server so it doesn't need to be copied. It's not really an interface, model, or service. Maybe something like would belong in utils, but it probably needs some more thought.
• We can use main...cross-process-server-model as a starting point, but this example should be streamlined and not used as-is.

[tjcouch-sil]

When we implement this change for the web-view.service.ts, let's move most of the utility code that is in paranext-dock-layout.components.tsx into the renderer version of web-view.service.ts as well as the import of testLayout. Most of that code is only in the component because web-view.service.ts is a shared file and cannot import the various renderer components and such.

[tjcouch-sil]

Let's also fix dynamic imports like this when we do that

[lyonsil]

To summarize the new pattern:

1. Determine if the service is essentially a "computation only library" where everything can be done in whatever process is running the code, or if there is a client-server nature to the service. If it is a computation only library, add the service to "shared" and you're done. Otherwise, keep going.
2. Decide which process (main, extension host, renderer) should own the server side of the service. Encapsulate that logic inside of a network object (or command if a network object won't work for some reason), and register that network object (or command) in a file named [service-name].service-host.ts in the src/[process-name]/services directory. Generally this is used by calling some initialize method from src/[process-name]/process-name].ts.
3. Extract an interface from that network object (or input/output types for a command) and put it inside of src/shared/services/[service-name].service-model.ts. This is generally where JSDOC comments for the service should reside. Also put the name of the network object (or command) inside of this service-model file. The service-host file will presumably reference the network object (or command) name from this service-model file.
4. Implement the client side of the service in src/shared/services/[service-name].service.ts. Generally this will just involve creating a network object in an initialize method and creating a small object that implements the model from the service-model file. All functions in the model should generally call initialize and the network object method or command.
5. As appropriate, expose the service's client object to papi-frontend and papi-backend.

The general motivations of this pattern are:

• Make code that can only run in one location obvious where it is running (i.e., the service-host code for one process).
• Make code that lives in shared truly agnostic to what process it runs in. We don't want to have to look at service code to read it all and see if there are isXXX calls to run code that will only run in one process even though the code lives in shared.
• Minimize duplication of logic and constants.