bug#35536: 27.0.50; Expose buffer's marker list to Elisp

[Drew Adams]

> >> What's _not_ available to users or Lisp code, I
> >> think, is the order of marker creation or even the
> >> order of last setting.
> 
> There's no reason for the C code to keep track of those things either.
> So while the current implementation may happen to have the markers in
> "creation order", it would be wrong to provide a primitive that promises
> this ordering unless there's a *good* reason why we'd want to force
> future Emacsen to also keep track of this info.  So far I don't see any
> such reason.

Fair enough.  I was thinking it might be a freebie.

E.g., I was thinking that the list to be returned
would just be created by, say, pushing new markers
onto it.  If that were the case then that order
could be useful, whether or not one could _depend_
on it.

Whether or not one should be able to depend on such
an order is a separate question.

If guaranteeing to provide such a default order is
too restrictive (and I agree that it probably would
be), but if the current implementation did mostly
return the set in such an order, then I'd vote for
not reordering it and just saying nothing about the
return order.

Consider `buffer-list', for example.  The order is
generally useful but we say nothing much about it,
directly.  (But we do show, in (elisp) `Buffer List',
how you can reorder the underlying buffer list.)

We also point out there of saying that `buffer-list'
"is not an internal Emacs data structure, and
modifying it has no effect on the order of buffers."