Do not evaluate u0 at problem creation and make p keyword

[devmotion]

I just noticed that it's a bit weird that we compute u0 when a problem is created for which only h is specified. IMO it's more reasonable to just assign u0 = h and compute the concrete u0 only when we compute a solution. By letting u0 be a function, it will be updated automatically if a change in the parameters affects the history function.

Moreover, I noticed that the current approach of dispatching on tspan::Tuple does not allow to specify both only h and a function for tspan. It seems we can resolve this problem by making p a keyword argument instead of an optional argument. However, I'm not sure if that's something we actually want to do. If it's OK, we should maybe handle parameters in other problem types in the same way for consistency. I added a deprecation warning for backward compatibility.

[ChrisRackauckas]

I'm not sure that we want to deprecate something so fundamental as how parameters are passed right now. That will need to be around a major release if we are going to do it.

[devmotion]

I agree. Just noticed this inconsistency, and couldn't think of a simple way to fix the ambiguities apart from changing the way we handle p.