Split Team model functionality to abstract and concrete classes

[jacobwegner]

Allow a:

• Abstract base class (created by, created, member_access, manager_access)
• Concrete class that implements the base class; no requirements for additional fields like name and slug
• "Default" class for the app (that implements the additional fields currently on Team)

This approach would allow a developer to implement a subset of the current teams app in a project (that, for example, may not require a name or slug field), while maintaining compatibility would current functionality.

It would also make it easier to derive a custom class at the project level to store project-specific data on that custom model.

[jtauber]

The concrete class with no additional fields could be called Role and the one WITH the additional fields could be called Team.