app server should not delete UtilityBitmap with delete

[bonefish]

When building libbe with DEBUG=1 the app server runs into the following assertion:

418: DEBUGGER: Deleted referenceable object that's not on the stack (this: 0x400ddc8, stack_base: 0x688c7000, stack_end: 0x68907000)

debug_server: Thread 418 entered the debugger: Debugger call: `Deleted referenceable object that's not on the stack (this: 0x400ddc8, stack_base: 0x688c7000, stack_end: 0x68907000)
'
stack trace, current PC 0x63356114  commpage_syscall + 0x4:
  (0x68905da0)  0x17133fd  _ZN14BReferenceableD2Ev + 0x129
  (0x68905f20)  0x127f79e  _ZN12ServerBitmapD2Ev + 0x80
  (0x68905f50)  0x127f822  _ZN13UtilityBitmapD1Ev + 0x26
  (0x68905f70)  0x127f846  _ZN13UtilityBitmapD0Ev + 0x1c
  (0x68905f90)  0x125e315  _ZN19BitmapDrawingEngine7SetSizeEll + 0xfb
  (0x68905ff0)  0x129e836  _ZN16DefaultDecorator19_GetBitmapForButtonEPN9Decorator3TabENS_9ComponentEbll + 0x14a
  (0x689060a0)  0x129ebba  _ZN16DefaultDecorator9_DrawZoomEPN9Decorator3TabEb5BRect + 0xbc
  (0x68906110)  0x129dbeb  _ZN16DefaultDecorator11DrawButtonsEPN9Decorator3TabERK5BRect + 0xd3
  (0x68906180)  0x129f2f2  _ZN16DefaultDecorator8_DrawTabEPN9Decorator3TabE5BRect + 0x462
  (0x68906300)  0x129caa4  _ZN9Decorator9_DrawTabsE5BRect + 0xc0
  (0x68906360)  0x129d31b  _ZN16DefaultDecorator4DrawE5BRect + 0x6b
  (0x689063a0)  0x1294e5a  _ZN6Window11_DrawBorderEv + 0xee
  (0x689063f0)  0x12966c9  _ZN6Window17RedrawDirtyRegionEv + 0x5b
  (0x68906430)  0x128e701  _ZN12ServerWindow14_MessageLooperEv + 0x221
  (0x689064c0)  0x12725ff  _ZN13MessageLooper15_message_threadEPv + 0xf
  (0x689064e0)  0xde7947  thread_entry + 0x1c

BitmapDrawingEngine::SetSize() deletes a UtilityBitmap, which is a BReferenceable, object with the delete operator. The reference count is 1, so that the assertion in the BReferenceable destructor is triggered.

Since it is impossible for the check to know whether this is erroneous use -- and the check itself is quite useful -- something else needs to be changed. One thing that comes to mind is using ReleaseReference() instead. Adding a Delete() method which could check the reference count, might be even nicer. Not sure, if adding a private delete operator would be possible to explicitly prevent it from being called.