Add a StepSizer based on quadratic interpolation

Interpolating step sizer implemented as a first step for adding conjugate gradient method in order to have a reasonable estimate for the initial step size (also for gradient descent method where it replaced ConstantStepSize).

It was necessary to change StepSizer interface because these estimates based on interpolation often need the descent direction that is readily available (some also need the previously accepted step size, but that one is harder to come by, most easily perhaps as ||x_k - x_k-1||).

The name QuadraticInterpolateStepSize could be shorter, but on the other hand it will rarely be used by the client code.
Because I don't want to jump far away from the initial location without knowing anything about the function, only its gradient at x0 which is a local information. Also, F(x0) is not NaN, so it is reasonable to expect that it won't be NaN in a "small" neighborhood of x0. And jumping far from x0 might get a point that satisfies Armijo or Wolfe conditions, but from that point the algorithm might converge to another local minimum, something the user might not want.

If we accept that dividing by the norm of the gradient is a good strategy then it is easy to see that there might be an index such such that x_i is large compared to step*grad_i, the difference being enough to floating point effects to take place and give innacurate x0+step*grad. Multiplying by the norm of x0 tries to avoid this at the expense of losing the invariance to translation.

Yes, it is a bit makeshift, but seems reasonable and at the first iteration there is not much else to do anyway. If the above seems too ad hoc, we can use simply min(1/|grad|_inf, 1): try a small step if the gradient is large, unit step if the gradient is "small" (because x0+1*small gradient will not move far from x0 anyway).

And yes, there will be cases where this strategy will not give a good estimate of the first step size and the line search will have a work to do. Having a set of benchmark problems would help to get at least some insight which strategy is expected to work better in general (I am adding implementations of test problems from More, Garbow, Hillstrom in another branch). But anything is better than a constant step size, like 1.