See #22630 and !9552

This commit:
 - splits req_smp into req_target_smp and req_ghc_smp
 - changes the testsuite driver to calculate req_ghc_smp
 - changes a handful of tests to use req_target_smp instead of req_smp
 - changes a handful of tests to use req_host_smp when needed

The problem:
 - the problem this solves is the ambiguity surrounding req_smp
 - on master req_smp was used to express the constraint that the program
 being compiled supports smp _and_ that the host RTS (i.e., the RTS used
 to compile the program) supported smp. Normally that is fine, but in
 cross compilation this is not always the case as was discovered in #22630.

The solution:
 - Differentiate the two constraints:
   - use req_target_smp to say the RTS the compiled program is linked
   with (and the platform) supports smp
   - use req_host_smp to say the RTS the host is linked with supports smp

WIP: fix req_smp (target vs ghc)

add flag to separate bootstrapper

split req_smp -> req_target_smp and req_ghc_smp

update tests smp flags

cleanup and add some docstrings

only set ghc_with_smp to bootstrapper on S1 or CC

Only set ghc_with_smp to bootstrapperWithSMP of when testing stage 1
and cross compiling

test the RTS in config/ghc not hadrian

re-add ghc_with_smp

fix and align req names

fix T11760 to use req_host_smp

test the rts directly, avoid python 3.5 limitation

test the compiler in a try block

align out of tree and in tree withSMP flags

mark failing tests as host req smp

testsuite: req_host_smp --> req_ghc_smp

Fix ghc vs host, fix ghc_with_smp leftover