Sequester all Skia<->DL interactions into the skia sub-module

[flar]

Most of the big objects that dealt with Skia interaction have already been moved into the skia sub-directory, but there were a few smaller uses of conversions that were scattered throughout the main body of DisplayList source code. This PR essentially pulled on a Skia root and kept pulling until a large number of Skia references were removed from the main body or sequestered into the skia sub-directory, including:

• Dispatcher was renamed to DlOpReceiver and many Skia enums and minor references removed from its methods
• DisplayListBuilder used to allow access to its OpReceiver methods through a public asReceiver() method. These methods now require special "friend" access only granted to a test file and a benchmark file that check regressions on internal state.
• Removed DisplayList::RenderTo(SkCanvas) method that knew how to interface with Skia. That code is now embedded in the DlSkCanvasAdapter instead and DisplayList only supports dispatching to a DlOpReciever now.
• moved SkPaintDispatchHelper into the skia sub-directory where its only use lies
• removed all "DlThing ToDl(SkThing)" converter functions as they are obsolete
• moved all "SkThing ToSk(DlThing)" converter functions to skia where their only uses lie
• moved all "DlThing::skia_object" methods into ToSk converter functions in the skia sub-directory where their only uses lie

There should be minimal use of SkObjects in the main body of the DL source code, but the following remain:

• Some test files use Skia objects to compare behavior of the DL equivalents
• Many interfaces still include SkScalar, SkRect, SkPath, SkMatrix, SkM44 and maybe a few other utility geometric objects

[flar]

@dnfield I removed a piece of code that protected color source access from the wrong thread in lib/ui/paint.cc when I removed the Paint::paint(SkPaint& paint) method now that it is no longer needed for the paragraph code. It feels like a similar protection is probably needed in DlSkCanvasAdapter and/or DlSkCanvasDispatcher which translate from DL objects to Sk objects for talking to an SkCanvas. The comment there indicated that the protection was only situationally needed when accessing a ui.Paint from the paragraph code. Is that still true after this re-configuration of the DL code?

Note that the paragraph code still calls the Paint::toDlPaint(DlPaint& paint) method which performs a similar operation for it, but entirely using DL data structures. That code doesn't have the "owner" protection in it, though...