Refactor IntegrationApi into separate concerns

[blingdahl]

Fixes #102

It's a good idea to open an issue first for discussion.

• Tests pass
• Appropriate changes to README are included in PR

[mryckman]

Thanks for the work on this! I like the idea of breaking this up. I know you're not looking for formal feedback yet... so just a few quick thoughts:

1. As a naming convention, I think it'd be wise to have the various sub-components of the historic IntegrationApi share a common pattern. Personally, I think it would work to refer to each of the as an "api." So maybe have something like handerApi, offerApi, and serverApi.
2. Continuing on the annoying problem of naming things, I'm just thinking out loud here, but this has made me wonder about the most intuitive way to segment stuff. I have this feeling like it might make sense to follow the broader way OPR divides up. Would a layout like this make sense?
   • serverApi: handler installers, router
   • hostApi: hostOrgUrl, various "offer" actions (get, accept, reject, etc.) - so mostly the current offermanager
   • storageApi: the storage functions
3. However these shake out, I do think it's important that integrations can access the various functionality as needed. It looks like this is how it's done and that an integration can just reference whatever components it needs. I just thought I'd mention it because it might be easy to take things away that somebody might need at an unexpected time.

[blingdahl]

@mryckman please take another look