Fix breaking change to scs_solve that was introduced by #311

[odow]

No longer breaking: 6e7bc7d...od/fix-compat-complex

[araujoms]

It would be helpful if you'd export or declare public the functions that shouldn't have breaking changes. Otherwise it's impossible to know what is considered part of the API and what is internal.

[kalmarek]

@araujoms the only function we export is the scs_solve itself;

@odow That we do it I personally consider a terrible choice. SCS itself does not keep the internal structures stable and these leak into our scs_solve signature; also that we go through scs_solve (which is impossible to use unless you read scs source) → _unsafe_scs_solve → scs_solve is a bit... confusing for anyone trying to figure out what is happening.

I'd suggest deprecating scs_solve in the next release and when nobody shows up to complain, simply removing it from the API. I see little value in supporting an interface "that someone might use some day, maybe".

[araujoms]

That's embarrassing. I always put the export together with the function itself, I assumed that it was also the case here.

In any case, I agree that scs_solve shouldn't be exported. Things are going to quickly get out of hand if some compatibility call every time SCS adds a cone. I'm glad it wasn't done before, otherwise it would already be a huge mess.