More conic problem utilities

Hi! This PR adds three new features:

1) sets ECOS as the default Conicsolver
2) adds a loadineqconicproblem! method (discussed below)
3) adds a default loadconicproblem! and loadineqconicproblem! method for LP solvers by calling loadproblem! (the method throws an error if you use non-LP cones.)

Regarding 2): I found that when using loadconicproblem! For certain problems, I was *introducing* slack variables to form the A, b, c, cones standard form, and then (effectively) replicating those variables when the problem was translated to ECOS standard form. To allow sophisticated users to avoid this replication, it seems nice to have a method that avoids translating between the two forms. If there's a way to do this that without breaking the unity of the interface, that would probably be preferable. 
yes, that's right. this is particularly useful in CVX.jl, so we don't need
to check if the problem is an LP in our parsing layer if the user has
provided an LP solver.


On Fri, Aug 8, 2014 at 6:59 PM, Iain Dunning <notifications@github.com>
wrote:

> In src/MathProgSolverConicInterface.jl:
>
> >
> >  for func in funcs
> >      @eval $(func)() = throw(MethodError($(func),()))
> >      eval(Expr(:export, func))
> >  end
> > +
> > +function loadconicproblem!(m::AbstractMathProgModel, c, A, b, cones)
>
> @madeleineudell <https://github.com/madeleineudell> I'm confused about
> what these two functions are for. It looks like they are a fallback for LPs
> that are provided as conic problems?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/JuliaOpt/MathProgBase.jl/pull/36/files#r16023652>.
>



-- 
Madeleine Udell
PhD Candidate in Computational and Mathematical Engineering
Stanford University
www.stanford.edu/~udell