Portfolio invitations do not associate a user entity until the
invitation has been accepted. User info, including DOD ID, is held on
the invitation itself. When a user accepts and invitation, their user
entry is associated with the corresponding `portfolio_role` entry.
The same change will be applied to `application_role` and application
invitations. For now, small changes have been made to
application-related methods so that that flow works as-is.
- raise specific invitation type if invite not found in invitation domain classes
- more terse assignments of defaults in invitation service, smh
- terser margin expression for inline input fields
- sass formatting
- use translation for cancel link
- oxford comma for app team management permission explanation
- do not format environment roles with hyphens for role selection
- generalize some additional methods in the invitation domain base class
- use plain atst.models import path
- domain method for creating a new application member
- ApplicationInvitations domain class
- nested form for adding a new user that holds user data, application
permission sets, and environment roles
- Invitation service can infer invitation type based on role it's given
- new invitation email templates
- add a base domain class
- extract shared model code to mixin
- rename invitation classes
- invitation model relationship to portfolio_role name is now more
generic "role"
