Signature converting functionality for (eventual) backend compatibility

[willGraham01]

Introduces the convert_signature function, which (given suitable information) can be used to convert the call signature of one function to another. This is a stepping stone towards the Translation and Translator classes that build on top of this, see #33.

convert_signature allows us to automate the process of mapping the signatures of some backend object to the signatures our frontend objects expect. It provides a means for a user to programmatically incorporate an unsupported backend into the framework that causalprog requires for solving problems.

TLDR / example

Suppose some custom library offers a means of drawing samples from a normal distribution, using the syntax backend_sample(number, seed). This function can be used to draw samples, in place of our native distributions. However, whilst the functionality is provided, the syntax is incorrect; our frontend expects to draw samples via sample(rng_key, sample_shape).

All that needs to be associated is that the rng_key parameter in the frontend should be passed as the seed parameter to the backend, and similarly the sample_shape parameter needs to be passed as the number parameter. This can be done via convert_signature, which essentially will return the function

def sample(rng_key, sample_shape):
    number = sample_shape
    seed = rng_key
    return backend_sample(number, seed)

Caveats

There are certain assumptions that convert_signature has to make in order to cast one signature into another. The function also needs to be provided with the mappings between parameter names, and (optionally) how to handle parameters that might need to be dropped.

convert_signature (and what is built on top of it in #33) is effective for those who want a "plug-and-go" style approach to the package, and is quite effective for just "inserting" a backend to be used in one-or-two places. If a user is planning to exclusively use a particular backend, they are likely better off creating their own custom classes to automate the process (to save repeat-passing of the information into the various Distributions they'll need to create).