app_server: Drop gfxcpy and implement some TODOs about checking for graphics memory.

We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.

On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.

Most of this code has not been touched since 2006 or so.

Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

app_server memory management: use ObjectDeleter to mark ownership

Make object ownership explicit by use of ObjectDeleter where possible.

Change-Id: I499a00aa3390d1510ae284419e73faffa5166430
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

made room for a new meaning of BitmapBuffer, it will be used for a RenderingBuffer class that wraps arround a ServerBitmap. BBitmapBuffer on the other side is handy as well and wraps arround a BBitmap, as BitmapBuffer did before.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13297 a95241bf-73f2-0310-859d-f6bbb57e9c96

made room for a new meaning of BitmapBuffer, it will be used for a RenderingBuffer class that wraps arround a ServerBitmap. BBitmapBuffer on the other side is handy as well and wraps arround a BBitmap, as BitmapBuffer did before.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13297 a95241bf-73f2-0310-859d-f6bbb57e9c96