Request for stack_include_contrib: Move s_test_case lines into a new file

[LukeLongworth]

As discussed in #1129, stack_include simply inserts the desired code into the question variables. This raises some problems when we include test cases in the same file as the desired inclusions.

• For large files, the compile time gets frustrating. I've found this whilst working on a linearalgebra.mac package. I've got a lot of rarely-used functions like SVD that aren't at all optimised, and if the code needs to run multiple test cases for every function, even unused ones, it drags on. I would happily divide up my file into multiple smaller ones if needed, I'm just not sure what people would find helpful, and there is a lot of dependency on earlier functions.
• Some test cases rely on simp:false. From what I can tell, s_test_case is an inert function from the perspective of the question, and the s_test_case.mac file forces simp:false. If the question using stack_include has simp:true then test cases that work with simp:false might return an error. I have a feeling that this could be worked around by setting simp:false IN the test, and then setting simp back to "normal" afterwards, but I'm not sure how to save the current simp state and return to it.
• I've found that if I ever have a question with random variables aa, bb, cc, etc (we avoid single character names as a style convention), then including the custom validators function causes problems because validate_interval_syntax complains that cc has been overwritten. This is definitely a me problem for overwriting basic functions, but it feels like this could be more broadly applicable as this contrib library grows in variability and use.

Would it be possible or desirable to move all of the s_test_case files into a separate file that s_test_case.mac checks, but isn't included with stack_include_contrib? Either one big file for all contributions, or a separate file for each contribution.

[sangwinc]

@LukeLongworth, I think we should move all the test cases into another file. Instead of X.mac we call it X_test.mac. That way, test files and their parent files correspond, but we only load the code. Putting all tests into one file would be messy.

[LukeLongworth]

Perfect, thanks Chris. This was exactly the type of solution I was hoping for!