Add fortran_open_s_ and fortran_close_s_ for single precision

[amontoison]

It's relevant if we want to use the same problem decoded in different precisions (single, double, quadruple) within the same code.
For example, there will be a conflict when calling fortran_open_ to provide the *.d file because the three libraries libcutest_single, libcutest_double, and libcutest_quadruple contain the same symbol.

We can do the same thing in quadruple precision with fortran_open_q_ and fortran_close_q_.

Off-topic: the mangling of symbols for quadruple precision is different from single/double precision. The first part (cutest) uses uppercase letters, which complicates writing multiprecision code.
An underscore is also missing at the end of the symbols, it should be *_q_.
All symbols are probably wrong in quadruple precision due to that.
It can be easily fix by adding a macro like it's done for symbols in single and double precision.

[amontoison]

I found a typo for a symbol in single / double precision:
CUTEST_cconst -> cutest_cconst_
CUTEST_cconst_s -> cutest_cconst_s_

We also have a header for CUTEST_cdimcop / CUTEST_cdimcop_s but it's not in the library libcutest_single / libcutest_double.

[nimgould]

I made the change fortran_open -> fortran_open_r (with r preprocessed to "", _s and _q as appropriate. Of course these routines are identical for all three precisions as they do not use reals.

Did you mean that CUTEST_const should say CUTEST_cconst (etc) in cutest.h? I agree

Yes, there is no routine cutest_cdincop so I have removed this from the header file

[amontoison]

Did you mean that CUTEST_const should say CUTEST_cconst (etc) in cutest.h? I agree

I got a wrong mangling as a consequence of this typo.
You fixed the root of the issue.

All symbols seem correct now.
Thanks, Nick, for fixing them.
I'm closing the issue.