Unify make-closure, make-interpreted-closure, and make-byte-code

Unify make-closure, make-interpreted-closure, and make-byte-code

[Thuna]

My understanding is that interpreted closures and bytecode are both
closures, just with different restrictions on what each slot can hold.
Given this, I can't help but wonder why we have three functions which
implement the same thing and do so in a completely different manner:

- `make-interpreted-closure' checks each argument individually, makes a
  vector of length 6, and passes it to Fvector with NARGS as small as
  possible.

- `make-byte-code' checks every relevant argument in one if statement
  (and signals an error that nothing else signals), and makes an
  arbitrary-long vector via Fvector.

- `make-closure' seems to (unless I am misreading it) copy a closure
  (and not a bytecode object as it says), change the constants, and
  return the copy.

`make-byte-code' and `make-closure' are essentially copiers.
`make-closure' straightforwardly so, and `make-byte-code' effectively
so, as it is primarily used (in core) in some variation of

  (apply #'make-byte-code (concat closure nil))

and on that note, I can't see any reason for `make-byte-code' to allow
an arbitrary number of arguments other than to support the above
pattern, and I personally don't find that to be a compelling case.

Putting aside concerns of backwards compatibility for a moment, what I
would expect is to have a `make-closure', a `copy-closure', and
functions for retrieving (and/or setting) each slot of closures (we
already have something like that in `interactive-form' and
`documentation'), with `make-interpreted-closure' and `make-byte-code'
being very small wrappers around `make-closure'.  I lean more towards
the current `make-interpreted-closure' as what `make-closure' should
look like, as that lends itself better to changing the slots around
without breaking code.

I think that it would be agreeable to backwards incompatibly change
`make-closure', as I see exactly one use of `make-closure' in core in
oclosure.el and exactly no uses in melpa or elpa.  `make-byte-code' can
also be deprecated in favor of a `make-compiled-closure' with better
interface, so as not to break existing code using `make-byte-code'
(though of course, any moving slots around will break almost all code
using `make-byte-code' regardless; that's why I want this change to
begin with).  This doubly so given the structure of closures is supposed
to be an implementation detail.

Some other solution is also fine; my motivation is to make it as
painless as possible to add a new slot to (the middle of) closures (see
https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01229.html and
https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00039.html for
context).