Add miscellaneous comments
Refactor rule definitions into per-pada lists

I've intended to make this change for a while and can't fully explain
why it seems better than the old approach.

To review: within a pada, the old approach would define certain subsets
of rules within multiple functions, decorate those functions with
@inherit, then collate those subsets into a single list of rule tuples,
which the system would process further into actual, usable rules. Pros
and cons are:

+ It's easy to define new filters, operators, and data without
  polluting the module namespace.
+ It's easy to create closures.
+ Rule tuples are created only when necessary and can be recreated if
  need be.
- Rule code feels a little scattered; ideally rules should sit close to
  each other.
- Decorators, as they are used here, are too "magical"; the why and
  where of rule processing is not immediately obvious.

Now the new approach. Within a pada, all rules are stored in a single
list `RULES`. Pros and cons are:

+ It doesn't matter if we pollute the namespace, since we import these
  modules programmatically and don't *-dump anything. It was never
  an issue.
+ Rules sit close to each other, which makes it easier to get an
  overview of the entire pada.
+ Rule tuples are never modified, so there's no need to worry about
  cloning them; we can just use the old ones.
+ We get a level of indentation back!
+ In general, the system is a lot more explicit.
- No easy closures, but there are some fixes for that.