bug#68244: hash-table improvements

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

15b6d72599b9 on master:

> +If you have code which creates obarrays as a simple Lisp vector:
> +
> +   (make-vector N nil)
> +
> +and then calls 'intern' using such an obarray as second argument, this
> +will now signal a wrong-type-argument error; replace nil with zero to
> +make it work again.

Thank you Eli, this might be useful, and you are absolutely right that we should help users fix their code.

But this cannot have come from nowhere. Did anyone actually tried to create obarrays in this broken way? It goes against all previous documentation and violates many invariants at once: it would have filled an obarray with multiple copies of the nil symbol which itself is interned in a different obarray.

Running `mapatoms` would have given very surprising results (what does nil have in its .u.s.next pointer? what happens if we remove nil from this pseudo-obarray?) and it must have been a recipe for accidents. It cannot have been a widespread usage.

And if anyone did try to create an obarray in that incorrect way, better recommend using `obarray-make` which is more future-safe than an already obsolete form.