The old DAP4 code assumed that all source files
on the server could be specified using a path string.
It turns out that for virtual files like .ncml files,
this is false and instead, a NetcdfFile instance must be used.

Fixing this necessitated some significant changes to the DAP4 code.
The basic fix was to make the primary DAP4 code operate with respect
to a DSP object. Then the problem was to change the code that invoked DAP4
so that it figured out what kind of DSP object to use.

The primary change on the server side is to provide a function that,
given an object, can figure out what kind of DSP to use to convert that
kind of object to a DAP4 representation. This is defined in the new class
called DapDSP.

As a rule, clients will end up using HttpDSP to read the
incoming DAP4 encode Http stream. Again as a rule, Servers will
assume an incoming Http request is for a NetcdfFile and will use
CDMDSP to convert that to a DAP4 Http stream. In the event that
Server detects that the file to be read is .nc, then it may
choose to use Nc4DSP to read the file, although it is not
required to and can instead open the file as a NetcdfFile object
and use CDMDSP.

The other major change in this PR, and the one that actually
prompted this whole change, is in the DapController and its
subclasses. Specifically, the function getNetcdfFile() has been
added to attempt to convert a String (a location) to a
NetcdfFile object (ultimately via DapDSP).  It is only if this
fails that an attempt is made to look for the other cases via
the location extension.

Misc. Changes:
- Remove DSPRegistry as no longer needed.
- Remove ThreddsDSP since it was just a wrapper around CDMDSP.
- Add a simple .ncml test case to show that NCML files could be served.
- Use #mode= to determine if DAP4 or DAP2 is to be used instead of
  #protocol= or #proto=. The latter two are still supported for
  back compatibility, but are no longer documented and are deprecated.