Openinviter integration

It should be fairly straightforward. You would simple copy/paste the Octazen engine into a new module, rename everything that references "Octazen", and alter the submit handler to use OpenInviter instead.

I've attached an integrated openinviter module. It's mostly copied from the dcl_importer module.

@hadsie this is really awesome. I really like how you've made the list of supported providers configurable. I've committed your code with just a few minor touch-ups.

awesome :)

Just a quick question... why did you move the hook_requirements into the .module file and cut out the install case? According to the hook_requirements docs "Note that this hook, like all others dealing with installation and updates, must reside in a module_name.install file, or it will not properly abort the installation of the module if a critical requirement is missing."

If there's no install case it's probably fine to be in the .module, but I think it should stay in the .install for consistency with drupal standards.

Also, I've attached a minor fix for a typo in the module that I'll commit myself.

@hadsie There's no logical reason that hook_requirements() is in the .module. I removed the $phase == 'install' one since blocking the install prevents the user from seeing the module settings page which offers some nice help on how to setup the library. I then re-added hook_requirements to give the warning about SQLite being required. But it should've gone in the .install file. The hook_requirements() for contact importer should also probably be in its .install file. When I originally wrote it I thought that since I was invoking hooks within it, that it needed to be in the .module file, but that doesn't make any sense.

Ok cool. I think it's good to remove the install phase in this case then. It also posed some other issues if users wanted to move the location of third party libraries.

Yeah we need to figure out how to handle relocation of the libraries gracefully. The emerging standard is to locate all external libraries in sites/all/libraries. Perhaps we need to just relocate them there. We should investigate WYSIWYG and see how it handles things since it does a similar one-module-many-libraries approach.

i've committed the fixes to the issues listed in #6