Removed 'register' storage class compiler warnings

Change-Id: Iba89a9d0845bf7e816983f903281d33e273f6e35
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5558
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

Change all references to "__INTEL__" to "__i386__".

They are functionally identical, but the former is a BeOS/Haiku-specfic
macro that we include in the compiler specs, and the latter is defined
by GCC.

app_server: fix gcc4 build

app_server: bitmap interpolation; fix out-of-bounds access

* Optimized code path for bitmap drawing with bilinear interpolation
scaling was assuming that source bitmap is always at least 2 rows
in size.

* Fixes #12469: in webkit, scaled 1-pixel-high bitmaps often occur.
If the bitmap allocation is by chance aligned to a page end, access
to the non-existant second row crashes app_server.

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 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.