more stable exponential

Three things:

1. I changed the LogCone definition
2. Can we have separate domain functions for LogCone and ExpCone?
3. I changed `x0` for the nonlinear cone to be strictly in the cone.

First, I changed the LogCone so it's
    
    y*log(y)  + x <= y*log(z)

This is OK, since the domain of the exponential cone assumes that `y > 0`. Technically, this is also equivalent to the closure of the exponential cone if you *define* `0 * -infty = 0`.

Editorial comments: apparently this is the one place where the solution is, "Did you try logarithms?" (And then get rid of division.) I don't have a good grasp on how this makes a difference, but, hey, it does.

The code passes the test cases, but I'm not sure if they still include exponential cones anymore.

Second, on line 57, we test if `(x,y,z)` is in the domain of the cone. Can this be broken out? I think the domain for the ExpCone and LogCone objects are slightly different.

Third, I return `[0, 0.5, 1.0]` as the initial point. I don't think the CP solver requires that the initial point makes `f(x) < 0` (strictly), but I figured it might be worth doing. Seems to help. Added bonus, closes #64.

```
     pcost       dcost       gap    pres   dres
 0:  0.0000e+00 -6.9315e+01  2e+02  1e+00  1e+00
 1: -3.0427e+01 -6.5103e+01  1e+02  5e-01  5e-01
 2: -4.0716e+01 -5.6887e+01  6e+01  3e-01  3e-01
 3: -4.3787e+01 -5.0874e+01  4e+01  1e-01  2e-01
 4: -4.4264e+01 -4.7115e+01  2e+01  7e-02  3e-01
 5: -4.3911e+01 -4.4901e+01  1e+01  3e-02  4e-01
 6: -4.3404e+01 -4.3676e+01  6e+00  2e-02  4e-01
 7: -4.2988e+01 -4.3067e+01  4e+00  9e-03  4e-01
 8: -4.2732e+01 -4.2807e+01  2e+00  5e-03  3e-01
 9: -4.2761e+01 -4.2673e+01  2e-02  5e-04  3e-01
10: -4.2674e+01 -4.2673e+01  2e-04  7e-06  4e-02
11: -4.2673e+01 -4.2673e+01  2e-06  8e-08  4e-03
12: -4.2673e+01 -4.2673e+01  2e-08  8e-10  9e-05
13: -4.2673e+01 -4.2673e+01  2e-10  8e-12  9e-07
14: -4.2673e+01 -4.2673e+01  2e-12  8e-14  9e-09
Optimal solution found.
```

Final comment on #70: I think this nondeterminism is a CVXOPT thing. With this pull request, I get the following kinds of errors:
```
  File "/Library/Python/2.7/site-packages/cvxopt/misc.py", line 451, in update_scaling
    z[:m] = base.sqrt( z[:m] )
ValueError: domain error
```
```
  File "/Library/Python/2.7/site-packages/cvxopt/cvxprog.py", line 1174, in cpl
    sigma = min(newgap/gap, (newgap/gap) ** EXPON)
ZeroDivisionError: float division by zero
```
If you increase the number of iterative refinement steps and add more static regularization, these don't happen "as often." The CVXOPT code just needs to be a little more elegant in handling the case when the gap is close to (in a floating-point sense) zero.