Handle osgi headers correctly

[kysmith-csg]

This PR fixes OSGI manifest processing. As it is now, this tool creates invalid manifest headers. My changes fix two problems that I saw while trying to use this:

1. Export-Package is not allowed to have a version range.
   The change by Set jakarta.servlet.* version range to [5.0.0,7.0.0] if specified #42 was too broad and would create things like

Export-Package: jakarta.servlet;version="[5.0.0,7.0.0)"

which is not valid in OSGI and results in the bundle not being installable. Now, it simply exports the single version:

Export-Package: jakarta.servlet;version="5.0.0"

I was a bit unsure what version to export though so I just went with the lowest.

Import-Package is unchanged because you are allowed to have a version range there.

2. Use org.eclipse.osgi as a dependency to process Import-Package and Export-Package. I have seen at least one case that a manifest had something like:

Export-Package: some.package;uses:="javax.servlet";version="1.0.0"

The regex pattern would see javax.servlet (after being transformed to jakarta.servlet) and change the version from 1.0.0 to [5.0.0,7.0.0), even though that version is for some.package.

Export-Package: some.package;uses:="jakarta.servlet";version="[5.0.0,7.0.0)"

This results in issues with other bundles who require some.package because they will be importing a version 1.0.0 which is no longer being exported.

By using org.eclipse.osgi we can parse the manifest headers as OSGI would and do it properly. I think it's impossible for a regex to match these perfectly.

[markt-asf]

The size of the org.eclipse.osgi JAR is a concern. At 1.5MB it would more than double the size of the migration JAR and increase Tomcat's footprint by 10-15%. I think this is a case where it would be worth writing our own parser. The risks/costs of writing and maintaining our own parser look to be worth it compared to the footprint costs.