Rolify lets us add “global” and resource-specific roles to our User
model.

Issue #299

This commit begins the process of adding roles to the User model by:

- Generating the role boilerplate and migrations
- Configuring Rolify (specifically, enabling dynamic shortcuts so we can
  do queries like `user.is_admin?` or `user.is_insights_user?`)
- Adding Role fixtures

It also moves the Devise stuff in the User model up next to Rolify, with
the idea that this sort of model-inheritance stuff should come before
the model-definition stuff.

Issue #299

This is a consequential commit.

Previously, we were defining admins by the presence of a `super_admin`
attribute on the `User` model. Now, we’re using Rolify with an `admin`
role. Consequently, this commit:

- Adds a (reversible) migration which finds all users with the
  `super_admin` attribute and adds the `:admin` role to them
- Updates the seeds file to create the admin user
- Removes the `User#super_admin?` method and converts all use of it to
  the `User#is_admin?` dynamic method created by Rolify
- Updates the `User` fixtures and tests
- Updates the `ARCHITECTURE.md` user model documentation

Issue #299

This commit adds the `new_user` and `insights_user` roles to users that
we create from applicants.

It doesn’t do this to all new users using an `after_create` callback on
the `User` model, as suggested by the Rolify docs, because we want more
control over when we assign these roles.

Issue #299

The `new_user` role distinguishes users who haven’t been through setup
yet from those who have.

This commit removes that role during account creation.

Issue #299

Issue #299

Prior to the existence of our roles and the `new_user` role, we were
using `user.sign_in_count` as a proxy for whether a user was already
setup, and thus whether we could send them setup instructions.

Now, we use the existence of the `new_user` role instead, as it’s more
explicitly intended for this.

Issue #299

Now that we have roles, we can target users more specifically for
specific tests. We also don’t need some of the duplicate test fixtures.

Issue #299

Since adding Rolify, we are triggering two significant Rubocop offenses:

- `has_and_belongs_to_many` is frowned upon in favor of
  `has_many :through`, but Rolify still uses the former. There have been
  many attempts to resolve this (see the Rolify issues and PRs) over the
  past decade, but none have fully landed. It’s beyond us to try and
  wrestle this into existence, so we’re going to make an exception and
  move on.
- The HABTM join table has no timestamps, which is also frowned upon. We
  genuinely don’t care, however, and so are making an exception.

Issue #299

This commit addresses some excellent @cguess feedback in PR #349:

- Disable the Rolify `config.remove_role_if_empty`, which would purge
  unused roles automatically once the last resource used them. We don’t
  want this until we know that we do.
- Seeds the database with the actual known/defined roles.
- Updates the documentation about our architecture with the roles.

Issue #299