Clarify that user sometimes must delete if managed [master]

[ see also !3 (merged) ]

I don't think I was fully aware of this until I noticed it incidentally during gtkmm#33 (comment 341220) in the gtkmm documentation. I think I took most of my assumptions about Gtk::manage() from gtkmm-documentation instead, which doesn't mention this at all.. and I think it is really worth being clear about, so future readers won't end up with leaky code like I now have to go and fix.

container.ccg remembers whether the object was originally un-floated by Gtk::manage() and, if so, restores that state during Container.remove(), with the result that the removed widget is not deleted, as it would be in GTK+, but instead it is re-floated and requires the user to deal with (e.g. to add it to some other container or to finally call delete on it)

This is documented in container.hg but nowhere that I can see in our tutorial, and I think it is worth mentioning here, since it is not completely intuitive: users might otherwise think that the fact manage() delegates lifetime management to the Container means they get back the same behaviour of C widgets, i.e. that remove() would cause destruction, but of course that is not the case, and we might thus encourage leaks.

So mention that manage() only relieves the user of the burden of calling delete if they add the widget to a parent and do not remove it later, in both the Memory Management section and the part about deleting wrappers.