Update remote app builder pattern

[twsouthwick]

PR Title
Update builder pattern for remote to clearly separate client and server scenarios

PR Description
This change makes a few API changes we've discussed around being clear around remote app options and extension methods. This introduces a new builder API (ISystemWebAdapterRemoteAppBuilder) that allows for a nested configuration pattern similar to the following:

ASP.NET Core:

builder.Services.AddSystemWebAdapters()
  .AddRemoteAppClient(remote => remote
    .Configure(options =>
    {
      options.RemoteAppUrl = ...
      options.ApiKey = ...
    }
    .AddAuthentication(true)
    .AddSession());

ASP.NET Framework:

SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .AddRemoteAppServer(remote => remote
        .Configure(options => options.ApiKey = ... )
        .AddAuthentication()
        .AddSession());

This change also separates out the options for Client/Server to be separate classes

Part of #112

[mjrousos]

Looks good. As I looked at the changes to samples, though, it occurred to me that we might be able to simplify the API a little by having AddRemoteAppServer and AddRemoteAppClient configure different interfaces (ISystemWebAdapterRemoteAppClientBuilder and ISystemWebAdapterRemoteAppServerBuilder). Then the extension methods that work on those builders wouldn't all need the "client" and "server" designations (since they would extend different interfaces) and overall usage would simplify a little.

[Tratcher]

We'll cover this in detail in the next API review.

[mjrousos]

Looks good. We should update docs to reflect the changes, too. If you want to do that in a separate PR, though, this part looks good.

[twsouthwick]

:) I was in the process of updating the docs so I wouldn't forget