add coupledSDEs type

[oameye]

resolves #202

This PR adds a new CoupledSDEs struct. Here, we follow closely the design of CoupledODEs:

struct CoupledSDEs{IIP,D,I,P,S} <: ContinuousTimeDynamicalSystem
    # D parametrised by length of u0
    # S indicated if the noise strength has been added to the diffusion function
    integ::I
    # things we can't recover from `integ`
    p0::P
    noise_strength
    diffeq # isn't parameterized because it is only used for display
end

Feel free to look at the documentation of CT to understand the API. The type should capture equation of the form $dx = f(x, p) dt +g(x, p) dW$. The function g both captures the noise strength $\sigma$ and the covariance matrix (correlation). In general, g can be quite an exotic function, making it that we lose both the noise strength and covariance matrix. However, we need this information to use algorithms in, e.g., large deviation theory. To solve this, I have opted for two design choses:

• During the construction of the CoupledSDEs the user can opt to give a noise strength as an argument. This noise strength will be saved inside the CoupledSDEs struct. However, during the creation the g wil also be rescaled with the noise strength. The parameter S in CoupledSDEs{IIP,D,I,P,S} indicated if this has happened or not.
• I have merged a PR in DiffEqNoiseProcess.jl that adds a covariance field to the noise process dW. This allows the user to add a correlated noise process like CorrelatedWienerProcess where the covariance matrix is automatically saved in the Integrator.

This solved the problem of not having acces to this information after the construction. Nevertheless, there is still some ambiguity as the user can always choose the g function freely. We can put the responsibility with the user and make tests that try to guess the type of noise. Or we will have to make subtypes such that we can easily distinguish scalar, multiplicative, additive, etc.

---

TODO

• [x] Make add covariance kwarg and giving g function optional
• [x] remove noise strength
• [x] We have to check if for SDEIntegrators a different step ReturnCode is possible.
• [ ] add benchmark with CoupledSDEs and SDEProblem
• [x] Think about naming kwargs and fields