Implement data interface for Raster types

[philippjfr]

In issue #542 we introduce a general API for N-dimensional, dense/gridded data. This provides the opportunity to adapt our existing Raster Element to use these dense data interfaces, which will allow these types to support various out-of-memory array storage formats including xarray, dask and iris directly and unify conversions between sparse and dense Element types.

Development of this feature should roughly follow these steps:

• Implement raw array based interfaces for backward compatibility.
• Update plotting code and operations to use new API rather than using .data directly

[philippjfr]

This has now to a large part been implemented but Raster itself is still a straggler and has not been converted. My suggestion for 2.0 is the following, the Raster Element will simply use the GridInterface, XArrayInterface and IrisInterface, when passed a raw array indices are added and it will use one of those interfaces to store the data. This preserves the semantics of Raster, i.e. integer indexed by default, but also provides a type that does not assume anything about the sampling of the data, which can be useful because Image and QuadMesh do and you might just want something quick and dirty.

[jlstevens]

Sounds like a reasonable suggestion to me.