Have IBIS `Model` class take responsibility for analog channel termination.

[capn-freako]

Issue Description

Currently, the __init__() function of the AMIModelInitializer class takes an optional channel_response keyword argument, which is expected to contain the complete analog channel response, including the analog termination of the IBIS model itself.

This is awkward because it means that the client code must:

1. peer into the IBIS(-AMI) model, to determine if it uses on-die S-parameters (only in the "-AMI" case) or lumped element parasitics to model its analog termination,
2. add such termination to the interconnect model, and
3. instantiate the AMIModelInitializer class with the resultant composite channel description.

A more elegant approach would be to just send in the interconnect S-parameters to the IBIS model initializer, letting the model itself take responsibility for choosing between on-die S-parameters and lumped element parasitics when completing the channel response, then making the thusly computed full channel response available as a property.

We might even go further, moving the pyibisami.ibis.model.Model class into its rightful position as the top-level API entity, offering access to an associated AMI model when appropriate, as well as a partially initialized (with the calculated channel response) AMIModelInitializer class instance.

Note: The only reason the current API isn't structured as described above is legacy: The PyIBIS-AMI Python package started life as nothing more than a very thin Python wrapper around the AMI DLL, nothing more.

Required Action

Let's introduce a new optional keyword: interconnect_network, to the __init()__ function of the pyibisami.ibis.model.Model class.
The IBIS model initializer will then use the interconnect response thusly provided to complete the analog channel response, as follows:

1. by combining it with the lumped element parasitics, in the case of either:

   • a non-AMI IBIS model, or
   • an IBIS-AMI model, which does not use on-die S-parameters.

2. by combining it with the network pointed to by the Tsfile parameter of an IBIS-AMI model that does use on-die S-parameters.

Furthermore, let's require that, when this new argument is provided, it must be one of:

1. a SciKit-RF Network instance, or
2. the name of a Touchstone file,

modeling either:

1. a 2-port (assumed differential), or
2. a 4-port (assumed single-ended) network.

Let's raise a ValueError if anything else is received in this new parameter.

Now, we don't want to break existing client code.
So, let's not change the semantics of the existing channel_response keyword argument to the AMIModelInitializer class __init__() function.
It shall remain the complete analog channel response, whether it is calculated by the (newly empowered) IBIS model initializer, or set manually by the user, as is the case today.

[mikelabonte]

The description makes sense to me. But I've barely used this code and I'm wondering, will users have a way to visualize the combined response and interconnect response, to confirm that the on-die channel had the expected effect?