Make the lottery accept multiple requests per student per timeblock with
priority, specified by a list of StudentRegistration types.

This might be kind of unfair since all of their requests are now
"stronger" than even the first request from a student with at least one
class. However, it's calculated dynamically so the advantage disappears
once they get their first class, and they don't get any extra priority
when we try to kick students, mostly just because that part of the code
is hard to reason about.

Classify requests by priority, calculate student happiness crudely, and
flag potentially buggy requests.

Take note of the "badness" of the assignment, which is how much it
overflows true class capacities, and add a "pessimism" parameter that
makes the algorithm more conservative about guessing that everybody who
wants to switch out will get to. This way the lottery can be tuned to
not overflow classes. This is a hacky workaround to patch the confusing
student-kicking algorithm applied to "fix" the greedy student-assigning
process, which doesn't always manage to get enrollments below true class
capacities.

This allows for better introspection (shell_plus can autocomplete the
parameters names), alerts you if you misspell a parameter name, puts the
default values right next to the option names, and generally shortens
the code a little.

Separate "orig" and "base" enrollments and capacities, "base" referring
to the state of enrollments after unenrolling students from classes they
want to switch out from, so that enroll_orig and section_capacities_orig
(among others) are consistent with each other about the state of
enrollments, and so that we have the section capacities needed to
print_stats accurately after assignments are saved.

- Make the previously hard-coded check-in room an option, and prompt for
  it as needed
- Slightly paranoidly confirm which email to send the class changes
  email from
- Text formatting

A lot of sums along some axes should have been "any"s.