Menu bitmap ownership handling

In OWLNext so far, the client application has had to manage the lifetime of bitmaps used on menus. It would be nice if the window owned the menu and its bitmaps and automatically cleaned up in TWindow::Destroy, as well as when performing changes to the menu and when replacing the menu (e.g. for menu merging).

As part of this change, making TMenu own its bitmaps would also mean that TMenu copy-constructors and TMenu::DeepCopy would become true deep copy functions. Currently, they do not copy referenced bitmaps.

See discussion for [bugs:#547] "MDI menu merging does not preserve bitmaps". As part of the resolution of this ticket, menu bitmap ownership has changed on the trunk, with the implementation of the new ownership currently in an experimental development state.

Note that while simplifying usage, this proposed change in menu bitmap ownership leads to substantial bitmap copying that didn't happen before, especially for MDI applications with menu merging (facilitated by menu descriptors). That said, it should have only an inconsequential effect on performance and memory usage, since these resources are relatively small, and duplicates are generated only temporarily during menu merging and other menu updates. Unless the client application keeps duplicates, only a single set of the bitmaps is held permanently by the final menu.

Still, copying static bitmaps seems a bit pointless. However, we can evolve this solution in the future, going from unique ownership to shared ownership. Shared handle ownership is already being trialled for TBitmap and other handle encapsulating types in our experimental branch Owlet. See "Shared-pointer semantics for handle-encapsulating classes" [feature-requests:#210].