Resource-management for resumptions #3
Description
As a follow-up to the discussion at https://discuss.ocaml.org/t/multi-shot-continuations-gone-forever/9072/13, I think the usual resource-management issues inside resumptions apply to resumptions themselves: currently they have to be dropped manually, which prevents us from referring to them inside other resumptions since it becomes impossible to track when they should be freed.
As suggested in the discussion, one solution is to make resumptions purely GC-managed values. To do so, one can represent a resumption either as a heap value obtained by copying a fiber, or as a fiber which is only discontinued by the GC using a finaliser and which is never reinstated/converted back to a continuation. The interface gets simplified by removal of demote, drop and Resumption_already_dropped.
The distinction between linear continuations, which are allowed to own resources, and multi-shot continuations, which are not, could be explained in the documentation, to underline the issues arising from promoting arbitrary continuations.
(cc @gasche)