Use modules for reflective subuniverses and modalities

This is option (4) at #596.  It's still a bit annoying, but I think it's made manageable by the technique of making the module types represent a _family_ of subuniverses or modalities.  The universe polymorphism is fiddly when defining particular examples, but once they are defined, it's basically invisible, which is how it should be.  Note that hardly any of the substantial code has to be modified; most of the changes are in the boilerplate.  There are a couple of minor anomalies that have to be worked around (still working on bug reports), but nothing too major.  Right now I think this is probably the way to go -- I don't even know how to do option (3) for lex modalities -- but I'd be interested in what others think.  I'm also very open to feedback on the best way to name and manage the modules; I proposed one possible convention, but I don't know that it's the best.
This is part of the "no constructing modules on the fly" restriction.  I'm not entirely sure what the reason is; perhaps it's because everything needs to have a unique name in the kernel, and `(Modalities_to_ReflectiveSubuniverses Os).foo` doesn't count as a "name", or perhaps it's because the module code is already complicated enough and they didn't want to make it more complicated.  (I'm leaning towards the former.)

I'd imagine that even in the case of `<:`, it might make some of the typechecking code significantly more complicated: the code checking that two types are the same might assume that every constant has a unique name in the kernel, so you wouldn't be able to reuse it to check that the given module actually implements the stated module type if that module type has no unique kernel name.