Add Dgecon and tests, plus small fix to Dlacn2

[btracey]

No description provided.

[kortschak]

That time-out during TestDgetrs is something I've seen before - I don't understand why the cgo tests take so long (the native tests are typically under ~10s for the long running ones here):

=== RUN TestDlange-2
--- PASS: TestDlange-2 (0.04 seconds)
=== RUN TestDpotrf-2
--- PASS: TestDpotrf-2 (6.29 seconds)
=== RUN TestDgecon-2
--- PASS: TestDgecon-2 (0.00 seconds)
=== RUN TestDgelq2-2
--- PASS: TestDgelq2-2 (0.00 seconds)
=== RUN TestDgels-2
--- PASS: TestDgels-2 (266.43 seconds)
=== RUN TestDgelqf-2
--- PASS: TestDgelqf-2 (105.36 seconds)
=== RUN TestDgeqr2-2
--- PASS: TestDgeqr2-2 (0.00 seconds)
=== RUN TestDgeqrf-2
--- PASS: TestDgeqrf-2 (87.53 seconds)
=== RUN TestDgetf2-2
--- PASS: TestDgetf2-2 (0.00 seconds)
    dgetf2.go:97: Returned ok with singular matrix.
    dgetf2.go:97: Returned ok with singular matrix.
=== RUN TestDgetrf-2
--- PASS: TestDgetrf-2 (28.46 seconds)
=== RUN TestDgetrs-2
SIGQUIT: quit
PC=0x555923
[snip]
*** Test killed with quit: ran too long (10m0s).

[kortschak]

work will not panic - "and Dgecon will panic otherwise."

Also below.

[btracey]

Does that ever happen to you locally? For me the full native suite runs in about 10s and the cgo suite runs in about 4.

[kortschak]

Never happens to me. I think it is something to do with Travis hardware and the way they deal with floats, but I have no evidence for that.

This LGTM with minor comments. Much clearer than the fortran which manages to make spaghetti out of 50 line routine.