bug#36649: 27.0.50; pure space and pdumper

[Pip Cet <pipcet@gmail.com>]

This is a follow-up to bug #36447, which has been fixed and closed.

Currently, pure space is wasted when using pdumper, and CHECK_IMPURE
does nothing at run time.

The current situation when using pdumper is this:

- pure space is put into the initial emacs executable as an all-zero
area with a single 1 in it, which is used to prevent the area being
placed into BSS
- before dump, data is placed into the pure space by purecopy
- before dump, PURE_P returns true for pure data, and CHECK_IMPURE
dies for pure arguments
- when dumping, pure data is indiscriminately mixed with impure data
and placed in the pdumper file without special treatment of any kind
- when launching the real emacs, pure space is also initialized from
the executable, as an all-zero area
- all data from the pdumper file is restored to heap memory, without
distinguishing formerly-pure data from formerly-impure data
- PURE_P is never called with a pure space pointer, it essentially
always returns false
- CHECK_IMPURE does nothing except waste a few cycles

That situation is unsatisfactory. We fail to catch modification of
formerly-pure data after loading the dump, and we waste several
megabytes of executable image size on zeroed data.

I think we have the following options:

1. remove pure space entirely
2. remove pure space, but leave PURE_P and CHECK_IMPURE as reminders
to do something about it.
3. move pure space to BSS
4. xmalloc() pure space, only when needed
5. modify pdumper to mark and recognize pure objects
6. do nothing and accept the wastefulness


I prefer (2), for this reason:

CHECK_IMPURE is useful, and should be extended to something like
CHECK_MUTABLE, which checks for objects including:

1. pure data
2. data read with `read'
3. data explicitly marked as immutable

(That would mean code like

(defconst list-a (nconc '(a b c) list-b))

would cease to be valid, and that's one of the problems I'm running
into with code I'm playing around with.)