Moved the load path UI into a separate source file

The load path UI is about to be completely rewritten to make it, er, well,
work properly. I expect this'll require a whole set of model classes for
the JFace TreeViewer; since these will only be useful for the load path
configuration page, there's no reason for them to clutter up ProjectUI
Added the first draft of the new load path user interface

This has even less functionality than the old one, but I think this will be
a much better foundation to build on
Don't hijack the JFace colour registry to colour load path controls

This new approach also gives us more power over precisely how these
controls should be rendered, although nothing uses that power yet
Added the rest of the controls to the new load path configuration page

Good! Good. Now all I need to do is make these controls actually do
something
Require that load path fake model objects carry indices around

This should be the only thing we need to be able to update the load path
properly. Now to implement the UI for actually making those updates
Made the Remove button on the load path preferences page work again

The Add button still just about works, but can only add SourceLoadPath
entries
Made the load path configuration page's "Up" and "Down" buttons work

These should probably be conditionally enabled. Then again, so should the
rest of the buttons, so that can wait for a dedicated commit
Don't create CoqPackageFragmentImpls for directories with invalid names
Added a wizard-based UI for adding new Coq load path entries

This UI doesn't work at the moment and can't be used to edit existing
entries. Both of these problems will be fixed over the next few commits
Made it possible to add abstract and project load path providers

This commit also necessitated a small change to the model: the
AbstractLoadPathManager.getProviders method now returns pairs of prefixes
and providers rather than just providers