Modularize SWT bundles/build into a set of fragments to the host that actually contain the source

[laeubi]

Current state

Currently there is one org.eclipse.swt that contains all the sources, and then there are org.eclipse.swt.<ws>.<os>.<arch> fragments (that don't contain any code), after the build the situation is completely reversed, org.eclipse.swt contains "nothing" but org.eclipse.swt.<ws>.<os>.<arch> contains the compiled code. This is not only confusing, but also complicates the build a lot.

Also there are different attempts and ideas to improve the situation already none of them really worked out well or required additional build extension support. I therefore like to propose a completely different approach, that even can lead to a better organization of the code and some kind of "modules-for-swt" system, what can become handy with the approaching Project Panama support where one probably want to integrate different libraries and native bindings that otherwise might overwhelm the already complex build structure of SWT.

Suggested target state

1. we make org.eclipse.swt a bundle that contains the code currently located in /bundles/org.eclipse.swt/Eclipse SWT/common
2. for each window-system we have a fragment org.eclipse.swt.<ws> with org.eclipse.swt as the host wich contains the ws specific java code
3. the org.eclipse.swt.<ws>.<os>.<arch> fragments do not contain any code but only the native binaries (DLL/so/...)
4. there may be even more specialized fragments e.g. org.eclipse.swt.win32.ole for functions dedicated to a feature not available on all OS (just an example)

That way we get (current state) three additional fragments that must be required by the host, but can build all of those as independent units, because of the fragment nature they later will be merged into one linear bundle-classpath and everything works smoothly and nice, also for the non-osgi case, just an additional classpath entry would be required to make this work.

IDE and Build support

One problem might be that there are cross references (e.g. the common part references a Label what is defined in the window specific part).

PDE: SWT uses the Eclipse-ExtensibleAPI: true header that should instruct PDE to make this "just work", if not we can/should enhance PDE for this use-case as there is already some kind of support for this.

Tycho: Tycho will certainly not be able to compile such setup out of the box but can be enhanced in the same way as PDE

A possible alternative would be to have abstract variant of such cross referenced types that are package private and their public api is abstract but public methods and/or field. That way we can even prevent a lot of current code duplication in such classes and the window system specific parts would only need to implement the abstract methods.