Playing with rescalings and starting dual vars

I'm in the middle of playing with different ways to rescale the problem
and different ways to choose the initial dual variable.  Originally, I
tried adding a rescaling of the form

A = h'(x)* L(h(x)) h'(x)

to the Newton system

H(x) dx = -grad f(x)

Bascally, that becomes

A* H(x) A dx = -A* grad f(x)

My hope was that I would be able to basically zero out the elements of
the gradient corresponding to the elements on the boundary.  In
practice, this worked poorly because the introduction of two of the A
operators in the linear sytem caused severe numerical problems.
Basically, we're inverting to A's.  As such, it appeared to behave
poorly.

Really, if we think about the current gradient calculation wih the
interior point pieces

grad f(x) - mu h'(x)* inv(L(h(x))) e

This kind of does the same thing.  If something is near the boundary, we
redirect the gradient in the other direction.  Well, we do if mu is
large enough.  As such, I added code to let the user choose an initial
mu more freely.  This led to an addition of news ways to choose the
initial dual variable.  Right now, I'm playing with setting

z = (mu <e,e> / <h(x),h(x)> ) h(x)

since the Hessian modification, in the case of bound constraints on x
becomes

inv(L(h(x)) L(z) = (mu <e,e> / <h(x),h(x)>) I

and the interior point estimate is

<h(x),z>/<e,e> = mu

Honestly, I don't think it works that well, but it's something to play
with.
Removed scaling and cleaned up new parameters

I removed the scaling from the previous check in and then cleaned up the
code related to some new diagnostic parameters.  Basically, in an
interior point method, we often shorten our steps to insure feasbility
with respect to the inequality constraints.  Before, all of this was
done internally.  Now, I added those parameters to the state and display
them when the msg_level is set to 2 or higher.  I did add these
parameters to the C++ code in the last check-in, but this check-in
cleans all of it up and adds it to MATLAB/Octave and Python.  I also
changed the choice of the dual variable back to what it was before in
the develop branch.  As such, all of the current unit tests should be
passing.
Added a scaled variant of an interior point method

I added sort of an odd, scaled interior point method as an experiment.
Basically, our complementary slackness condition is normally relaxed
into

h(x) o z = mu e

Instead, I relaxed it into

h(x) o z = mu h(x) o h(x)

This gives a gradient modification of

- mu h'(x)* h(x)

and a Hessian modification of

h'(x)* inv(L(h(x))) (
    h'(x)dx o z - mu h'(x)dx o h(x) - mu h(x) o h'(x)dx)

with a merit function modification of

-(mu/2) < h(x), h(x) >

Overall, it only works ok and I'm not fully convinced that it works with
first order algorithms.  The idea behind it was to create a situation
where z was encouraged to become mu h(x).  This helps moderate the
conditioning of the Hessian modification.  In addition, if we look at
the contour plots of

x y - mu = 0

we see that the graph approaches 0 as either x or y gets large.  For
poorly scaled problems, this feels like it causes an issue.  Conversely,

x y - mu x^2 = 0

asks y to also get large if x is large, which seems like it should work
better for poorly scaled systems.

In any case, I'm not all that happy with the performance, but I thought
the code was interesting enough to check in.
Revert "Added a scaled variant of an interior point method"

This reverts commit 41678aa22dc9c28dd7afe8ee9c35dc6b94bbf23e.

Basically, I dont think the algorithm is working well enough for entry,
but it was interesting enough to keep in the history for later
consideration.
Changed our initial z to be mu inv(L(x)) e

I change our initial inequality multiplier to be

z =  mu inv(L(x)) e

where mu is chosen by the user and has a default of 1.0.  In this way,

h(x) o z = mu e

and

mu_est = < h(x) , z > / < e , e > = mu

Technically, I had this code floating around from some previous changes,
but I just reenabled it.  Really, by messing with the initial mu, we can
force the step to be more or less internal to the problem.  This
provides an ability to tweak a problem to force things to work in many
cases.

In addition, I cleaned up the code regarding alpha_x and alpha_z.  Now,
it correctly outputs to our diagnostics.  Specifically, we only see
alpha_z when doing a PrimalDual interior point method and not with the
other methods where we ignore this parameter.

I also updated the manual and correctly document the changes to z,
alpha_x, and alpha_z.
Merge branch 'feature/iterior_point_scaling' into develop