Modification of OsgiClassPathLocationScanner to support not only current bundle

[dzharikhin]

enhancement for #1142.
Makes OsgiClassPathLocationScanner try to get target bundle from url first instead of the current one if possible. If it's not possible it still keeps fallback to current bundle

[axelfontaine]

I saw you closed the original issue. Is this PR still relevant? For what environment/constellation exactly is current situation a problem that would be resolved by this?

[dzharikhin]

Hi! Yes it is. I closed the ticket just because all the info related is here.
This PR allows you to search migration files in another bundle.
My example is: I build on demand migration service based on OSGi, which is the one who knows about DB. So, other OSGi bundles just consume this service on install phase to support their own "sub-schemas"

[axelfontaine]

I am still not sure I fully get it. Which OSGi runtimes are affected by this? Why aren't fragments sufficient to solve this?

[dzharikhin]

Well, now I'm trying to integrate Flyway into Atlassian products, their plugin infrastructure.
Instead of ActiveObjects I suggest to use Flyway+MyBatis.
In Jira plugin is a bundle, but there's no way to create a fragment-bundle there. But I need to use resources from these plugins to execute migrations related to specific plugins.
That's why I need this so much

[axelfontaine]

Thanks! Merged.