Revert "*evr, *stevr: use fast CSTEMR path for partial eigenvalue ranges on I…"

[langou]

Reverts #1295

This creates quite a few failures on my laptop and on @jprhyne's laptop.
I am reverting this PR. Thanks to @jprhyne for doing the dissection to find the problematic PR.

[langou]

With this PR in, I had:

			-->   LAPACK TESTING SUMMARY  <--
		Processing LAPACK Testing output found in the TESTING directory
SUMMARY             	nb test run 	numerical error   	other error  
================   	===========	=================	================  
REAL             	1435068		292	(0.020%)	0	(0.000%)	
DOUBLE PRECISION	1435890		299	(0.021%)	0	(0.000%)	
COMPLEX          	919300		294	(0.032%)	0	(0.000%)	
COMPLEX16         	920367		312	(0.034%)	0	(0.000%)	

--> ALL PRECISIONS	4710625		1197	(0.025%)	0	(0.000%)	

If I revert this pull request with git revert -m 1 05a6d9f4e9004977b6ecc045ec1c42756134468e then I get

			-->   LAPACK TESTING SUMMARY  <--
		Processing LAPACK Testing output found in the TESTING directory
SUMMARY             	nb test run 	numerical error   	other error  
================   	===========	=================	================  
REAL             	1569708		0	(0.000%)	0	(0.000%)	
DOUBLE PRECISION	1570530		0	(0.000%)	0	(0.000%)	
COMPLEX          	1029460		0	(0.000%)	0	(0.000%)	
COMPLEX16         	1030527		0	(0.000%)	0	(0.000%)	

--> ALL PRECISIONS	5200225		0	(0.000%)	0	(0.000%)	

I use -O0 to compile and this is on my Mac M4-based laptop. @jprhyne observes the same thing on his Linux AMD-based laptop.

[langou]

That being said the idea behind the PR is good. I did not have time to look too much into it on whether this is an error deep in STEMR when we use RANGE (since this has not been much tested, since this was never really enabled by HEEVR), or if this is something in this PR in itself. It would be good to have this working one day.