add support for iterative build of OpenBLAS with 64-bit integers

[jfgrimm]

(created using eb --new-pr)

[akesandgren]

I don't think adding _ilp64 suffix to the actual symbols is a good thing. Most codes I know of that does use ilp64 blas just assumes that the symbols are the same as usual. I know I never did that when compiling it with 64bit integers way back and the codes that relied on it worked just fine that way

[jfgrimm]

@akesandgren good point, I've switched back to using LIBNAMESUFFIX

[migueldiascosta]

I agree it's simpler not to suffix the symbols, but otoh, numpy suggests using them to avoid clashes (https://numpy.org/devdocs/user/building.html#bit-blas-and-lapack), and SciPy says they actually need both (https://scipy.github.io/devdocs/dev/contributor/building.html#reference-for-build-options)...

Could we build all three variants?

[jfgrimm]

@migueldiascosta so, two 64bit iterations: one iteration with INTERFACE64=1 SYMBOLSUFFIX=64_ and one with INTERFACE64=1 LIBNAMESUFFIX=ilp64 ?

[migueldiascosta]

overriding the symbols is SYMBOLSUFFIX= (empty), I think

(edit: noticed now that I misread the above, so nevermind)

[akesandgren]

Conflict resolution needed.

Also, I think we should try to get both the plain 32bit int and the 64_ symbol suffix functions into the same libopenblas.(a|so) library in case that isn't already part of this change.