Extension storage based on Java Service Provider (META-INf/services)

[decebals]

This pull request comes with some improvements related to how we store metadata related to @Extension in files.
Until now we stored the metadata for extensions in a META-INF/extensions.idx (one file per plugin, the format is one text line with extension class name for each @Extension). I propose you a more standard location and format, META-INF/services/<extension-point>, used by Java Service Provider (see java.util.ServiceLoader).

The old format (META-INF/extensions.idx):

ro.fortsoft.pf4j.demo.HowdyGreeting
ro.fortsoft.pf4j.demo.WhazzupGreeting

The new format (META-INF/services/ro.fortsoft.pf4j.demo.api.Greeting):

# Generated by PF4J
ro.fortsoft.pf4j.demo.HowdyGreeting
ro.fortsoft.pf4j.demo.WhazzupGreeting # pf4j extension

More, I introduced with this PR a new abstraction ExtensionStorage so you can write and use your own storage.

My goal with this PR is to improve the adoption of PF4J, to allow other people to jump ease from ServiceLoader to PF4J.

The new versions of PF4J can work OK with the old format, extensions.idx (the DefaultExtensionFinder is a compound between ServiceProviderExtensionFinder and LegacyExtensionFinder).

[decebals]

I think that I finished the work at this branch.

So, in few words, this branch add:

• the possibility to change the ExtensionStorage in ExtensionAnnotationProcessor(for now we will use yet the old format with META-INF/extensions.idx)
• read META-INF/services (Java Service Provider mechanism) as extensions; if you have a modular application based on ServiceLoader class you can replace entirely ServiceLoader.load()call with PluginManager.getExtensions() and migrate smooth from ServiceLoader to PF4J