Support partially overlapping operator implementations

[dextorious]

Consider for instance the case du(t) = A(t)u + B(t), where A(t) = A1(t) + A2(t) and B(t) = A1(t) + B1(t). The current implementation would require doing the calculation for A1(t) twice, sacrificing some performance. While hackish workarounds are easily possible for simple cases, ideally a more flexible general solution should be found giving the users the expressive power to specify more details about how they prefer to structure the computation.

[ChrisRackauckas]

The thing that makes this difficult is that update_coefficients! is defined for the individual operators. It seems that this suggests constructing the affine operator outright. Maybe that's the right idea? I'm not sure how to go about this though, but it seems necessary to get good performance in some cases.

[dextorious]

Well, there's a couple of solutions that I can see, but all seem unsatisfying in different ways. One is to construct the affine operator outright, as you said. Another might be to introduce an update_coefficients_shared! call that gets run first, but then managing data encapsulation gets annoying. A third might be to abuse call overloaded types to introduce an additional cache in the update_coefficients! type itself, but that requires access to the data of the other operator to be useful, etc.

Right now, I'm not sure which version is less painful.