implement abstract InvitationService interface

[lsloan]

The CirrusInvitationService (renamed as suggested in the quote below) needs to be based on a new, abstract InvitationService interface. That way, invitation services other than Cirrus can have new services implemented for them, as needed.

Originally posted by @ssciolla in #247 (comment)

Extra credit: What if this was CirrusInvitationService? I guess I was thinking that we could have the class implement an InvitationService interface, and then have it dynamically load the correct module based on what provider is configured. That's probably too fancy at this point, but one of the big hurdles I see to this tool being useful to other institutions is that they either don't have a service like Cirrus or they have another one.