app_server: fix tiled drawing when phase is outside bitmap bounds

sourceRect has phase baked in. If phasecomponents are larger than bitamp bounds
sourceRect no longer intersects and nothing gets drawn.

Change-Id: Ib3f676b8e78e2d941c89e699f9a0ab39cc93e173
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2916
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

app_server: Add tiled bitmap drawing routines

Change-Id: I9a7bd967f2cc95d815a66707b764cf5e33b3f8ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1962
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

app_server: gcc4 build fixes

app_server: bilinear bitmap painting: alpha overlay support

* Add support for pixel alpha overlay mode in the optimized bilinear-
scaled bitmap drawing code of BitmapPainter.
For now, only BilinearDefault supports this. DrawBitmapBilinear
gets the colour type and draw mode as template parameters to
minimize code duplication and allow simple extension with further
pixel formats and modes.
Avoids, for this mode, fallback to the slower generic
AGG-pipeline-based version.

app_server: add alpha masked mode to DrawBitmapNoScale

* Add another mode to DrawBitmapNoScale for drawing bitmaps using
B_OP_COPY with alpha masks. It behaves like the definition for
ClipToPicture from the BeBook: pixels with alpha = 0 are ignored,
pixels with any alpha > 0 are copied.
Before, this fell back to the slower generic AGG-pipeline-based
version.

* Some light refactoring

app_server Painter: refactoring, extract bitmap drawing

* Extract bitmap drawing from Painter into separate class
Painter::BitmapPainter. This will allow to add new optimized
drawing modes without making Painter larger.

* BitmapPainter itself is further decomposed into separate
(method object) structs per drawing mode (currently, those are:
generic, no scale, nearest neighbor, bilinear). New optimized
implementations can be added by writing additional method objects
and calling them from BitmapPainter.

* DrawBitmapNoScale and DrawBitmapBilinear are implemented using
CRTP. This removes the function pointer in the 'no scale' version,
which was previously used to select the row copy type. In the
bilinear version it untangles the three variants (default,
low filter ratio, SIMD) into separate methods.

* While BitmapPainter is a nested class in Painter, the specialized
method objects are not. Instead, the AGG-specific data fields from
Painter are moved into a new struct PainterAggInterface. This
struct is passed to the method objects and allows them to access
the Painter's AGG renderer/rasterizer/scanline containers/etc.

Alternatives would be to make all the involved structs friends
of Painter, or nesting them all, or exposing all of Painter's
internals via getter methods -- all of these would be quite messy.

The details of the bitmap painting implementations are
intentionally hidden from Painter: there is no need for it to
know about their internals -- it does not even know their type
names. (Nesting or making them friend would expose their type
names to Painter.)

Furthermore, there is another level of information hiding between
BitmapPainter and the DrawBitmap[...] method objects.
BitmapPainter itself only needs to decide that it uses e.g. the
bilinear version. It has no knowledge that DrawBitmapBilinear is
internally made out of several structs implementing specially
optimized versions.

* Refactoring only, no functional change intended. Performance
should be unaffected.