Makes the rules more uniform in structure and style. This makes it
easier to automate subsequent commits. No behavior changes.

Unblocks converting the rules from one big string to a rich data
structure.

Eliminates a redundancy between the 'rules' suboptions and the type
specified in each rule.

We eventually want to give each rule a name so that we can merge config
overrides. The PAM name is a natural choice for rule name, but a PAM is
often used in multiple rule types. Organizing rules by type and rule
name avoids name collisions.

Allows us to decompose rules into multiple fields that we later format
as textual rules. Eventually allows users to override individual fields.

These names are internal identifiers. They will be used as keys so that
users can reconfigure rules by merging a rule config with the same name.
The name is arbitrary. The built-in rules are named after the PAM where
practical.

Module arguments have common escaping rules for all PAMs.

Adds easily overrideable settings for the most common PAM argument
styles. These are:

- Flag (e.g. "use_first_pass"): rendered for true boolean values. false
  values are ignored.

- Key-value (e.g. "action=validate"): rendered for non-null, non-boolean
  values.

Most PAM arguments can be configured this way. Others can still be
configured with the 'args' option.

Makes it possible to override properties of a rule by name. Introduces
an 'order' field that can be overridden to change the sequence of rules.

For now, the order value for each built-in rule is derived from its
place in the hardcoded list of rules.

Removes redundant config from the module. Fixes a bug where some modules
(e.g. ussh) were added to apparmor even though they had no rules enabled.