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
Force the creation of output folders

It seems that, when importing projects, resources which exist on the
filesystem might not yet exist in the Eclipse workspace. This commit stops
that from being a problem
Removed the "prefix" attribute from the load path provider extension point

All load path providers are now queried for all identifiers; that API is
about to change to make it possible to return more nuanced answers, though
Extended the AbstractLoadPathProvider interface

Providers now return implementations for a given abstract load path. These
might or might not actually work, depending on lots of external factors,
but now they have some way of indicating what might be wrong with them
Changed the way the load path configuration UI presents load path providers

Providers are now treated as parent elements, with the implementations they
provide displayed as children -- unless they only have one implementation,
in which case that's just shown directly
Show error messages when abstract load path providers don't work

In future, this bit of the UI might even offer some way of fixing these
problems -- but, for now, just reporting them is a good start
Abstract load path implementations should be able to return their provider

Implementations are essentially supposed to be lightweight handles to
(potential) libraries. Anything more complicated than that, like actually
installing libraries, should be managed by providers
Added some more safety checks to CoqAutoEditStrategy

For boring technical reasons, events with an offset of 0 were causing
strange things to happen, so those are now handled specially; events
happening past the end of the document will now also be removed
Allow offsets to be set and retrieved for certain kinds of scanner
Generalised the Coq partition scanner a bit

It should eventually be possible to recognise Java partitions using this
newly-general infrastructure, and thereby to add support for using Coqoon
services within Java editors
Added a missing wildcard to the model's classification code

Mysteriously, Scala 2.10 accepts this code, even though it was obviously
broken. Scala 2.11, however, complains, and it was quite right to do so