Always build support for the external interpreter

You can always just not use or even build iserv. I don't think the maintenance cost of the CPP is worth...I can't even tell what the benefit is.

OK per the comments the benefit was being honest about AIX. But I believe the situation is when the target is AIX, not host, so it more honest thing to do is still get rid of the CPP and switch to a runtime condition instead.

To do that right, however, I had to shave a few yaks:

1. Factor out a PlatformMini from Platform for the few cases we've accumulated now where we fallback on target := host absent a settings file.
2. Make the settings file parsing code not blow up on failure. This opens the door the sharing more of that code with ghc-pkg.
3. Make a tryFindTopDir to find the top dir without blowing up

The end result is ghc --suppported-extensions will spit out the correct result for the target platform. It will work whether or not the settings file exists (thought it will blow up if it contains invalid data), falling back on what little it knows about the host platform if it doesn't.

CC @alp @angerman @hvr

• are either individually buildable or squashed
• have commit messages which describe what they do (referring to Notes and tickets using #NNNN syntax when appropriate)
• have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places.
• add a testcase to the testsuite.
• replace this message with a description motivating your change

If you have any questions don't hesitate to open your merge request and inquire in a comment. If your patch isn't quite done yet please do add prefix your MR title with WIP:.