Support for language statement, part 2

A much better version of #119, including optional support for sublanguages.

Fixes #111.

This should satisfy @Toxaris requirements I could collect:
> - "falling back to fomegastar" is removed, the language command-line flag has the same semantics as the language statement, and annotating no language at all is an error.
> - For backwards compatibility: If a user selects a language at the command-line, the PTS interpreter must not use any other language in the same run.

However, I didn't rebase old code, but cherry-picked and resplit the code and went testing on the way.
I tried to ensure that every commit passes the testsuite (which I think I managed), and that the resulting code makes sense on its own. (So I first build internal support for some feature, and then the user-facing support for it).

Missing:
- when an import fails because it uses the wrong language, the error location should not be (just) the import location, but also the language statement inside the imported module.
- consider changing the type of `Options` to contain `PTS` rather than `Maybe PTS` using `withReader` during typechecking, so that it is statically known not to fail (while currently I use `fromJust` and just ensure it won't fail).
This is a bit tricky, because `processFileInt` needs to overload the lookup of the current language to work both when called from the command line and when called recursively.
Moreover, this involves reviewing every occurrence of `Options` to see if it should be `CmdlineOptions` or `OptionsStruct t`.
- maybe we should enable sublanguages by default — this will be needed for `UU.lpts` once reusable imported modules add useful `language` statements (say, most of `Data.*` needs `language fomega`).