bug#46916: 28.0.50; pure_alloc(10424, ...) fails badly when pure space is exhausted

[Pip Cet]

Pure space should be removed. But until it is, it shouldn't exhaust
all virtual memory, crashing the machines of the unwary ones who tried
to build emacs without a ulimit...

The problem I ran into was that the native-comp branch calls Fpurecopy
on comp_u->data_vec. In my case, pure space was already exhausted and
data_vec had 1302 elements.

That caused purecopy() to call pure_alloc with a size argument of
10424. pure_alloc allocated another 10000 bytes of fake pure space,
found out those weren't enough, so it allocated another 10000 bytes of
fake pure space, which weren't enough, etc., until the process started
swapping.

I'm not sure who's the culprit here: the native-comp branch tries to
purecopy a large vector, which is a problem; purecopy() saw that
request and passed it on to pure_alloc(), rather than returning the
impure vector because it was too large. And pure_alloc() certainly
should fail more gracefully than it did (there's an eassert() to
prevent this situation, but that should be unconditionally compiled
instead).

I was going to write a message to emacs-devel (I'd started before
hitting this bug) proposing to remove pure-space now, but I think it's
fair to have a separate bug report if we decide to keep pure space
after all.