Eradicate use of MAKE-EQ-HASH-TABLE.

Eradicate use of MAKE-EQ-HASH-TABLE.

Replace each use by a constructor with a more specific name.
Full analysis:

* Use of MAKE-EQ-HASH-TABLE in MIT Scheme, 2009-12-21  -*- outline -*-

In MIT Scheme, MAKE-EQ-HASH-TABLE yields a hash table whose keys are
held only weakly, so that they will be garbage-collected if there are
no strong references to them.  To make a similar hash table whose keys
are held strongly, one must use MAKE-STRONG-EQ-HASH-TABLE explicitly.
Of the sixty-two uses of MAKE-EQ-HASH-TABLE throughout the MIT Scheme
source code, only four appear to need weak references to their keys,
and for only two more is there an obvious reason to use weak
references.  This list categorizes most uses of MAKE-EQ-HASH-TABLE.

Each entry is marked by the decision that was made for it of whether
it should be strong or weak.

** Hash table must be key-weak

*** [weak] edwin/curren.scm, screen-buffer-layouts
*** [weak] edwin/eystep.scm, stepper-buffers
*** [weak] edwin/xterm.scm, display/cached-atoms-table
*** [weak] edwin/xterm.scm, display/selection-records

** Hash table should be key-weak, but will work as key-strong

*** [weak] edwin/comman.scm, permanent-local-variables

As long as Edwin variables are strongly interned, it is safe to use a
key-strong hash table for properties on Edwin variables such as the
permanent-local property, but if Edwin variables were weakly interned
then this would be a space leak.

*** [strong] sos/class.scm, built-in-class-table

Dispatch tags that are garbage-collected shouldn't accumulate space
here.  These might arise, for instance, from re-evaluating
DEFINE-RECORD-TYPE forms causing the old record type's dispatch tags
to be garbage-collected.  That requires key- and datum-weak hash
tables, though.  Using MAKE-WEAK-EQ-HASH-TABLE here breaks the
bootstrap from the 20090107 snapshot, which doesn't have a binding for
that name.  So just use a strong eq hash table for now.

** Hash table should be key-strong, but will work as key-weak

*** [strong] compiler/machines/i386/lapopt.scm, *rules*

If the compiler never generates instructions with certain symbols in
them, and hence the compiler's code has no strong references to those
symbols, then the rules for those symbols may as well be discarded.
But that's pretty sketchy.

*** [strong] compiler/machines/svm/assembler-runtime.scm, symbolic-operators
*** [strong] compiler/machines/svm/assembler-runtime.scm, pvar-type-table
*** [strong] compiler/machines/svm/lapopt.scm, *rules* (not really used)
*** [strong] compiler/machines/x86-64/lapopt.scm, *rules* (not really used)
*** [strong] edwin/nntp.scm, equivalences in build-equivalence-classes

The only reason that this works as a key-weak hash table is that every
key is also strongly referenced by the hash table's data.

*** [strong] edwin/nntp.scm, tables in convert-header-graphs-to-trees

In the only caller of CONVERT-HEADER-GRAPHS-TO-TREES, the (strong)
list of headers is still strongly referenced, so the keys of the two
hash tables in TABLES will not be garbage-collected.

*** [strong] edwin/xterm.scm, built-in-atoms-table

If the binding for BUILT-IN-ATOMS were collected while that for
BUILT-IN-ATOMS-TABLE were not, then the latter would be in trouble.
This generally doesn't happen currently.

*** [strong] microcode/os2pm.scm, type-abbreviations
*** [strong] microcode/os2pm.scm, id-external-roots

This code is probably defunct, but if it weren't, and if the
presentation manager procedure abstraction were used outside this
file, it would probably be necessary to make these two hash tables
key-strong.  Another hash table, PM-PROCEDURES, is incorrectly
key-weak.

*** [strong] runtime/genio.scm, {en,de}coder/sizer/{,de}normalizer maps

Since there are maps in both directions, each hash table's keys also
have strong references in the data positions of the other hash table.
But this is pretty fragile, and in any case there is no need to use
key-weak hash tables.

*** [strong] runtime/syntax-output.scm, unmappings
*** [strong] runtime/syntax-output.scm, rename-databases' mapping-tables
*** [strong] runtime/syntax-output.scm, rename-databases' id-tables
*** [weak] ssp/xmlrpc.scm, methods in get-xmlrpc-method-handler

Since the hash table is used only in one place, and only one key is
fetched out of it, that key will be strongly referenced until it is
fetched, and the other keys don't matter.  (For that matter, why use a
hash table at all?)

*** [strong] xml/turtle.scm, table in write-prefixes

** Hash table must be key-strong

*** [strong] compiler/machines/svm/assembler-runtime.scm, symbol tables

These are probably meant to be treated like the symbol tables
implemented in compiler/back/symtab.scm.

*** [strong] imail/imail-file.scm, file-folder-types
*** [strong] imail/imail-mime.scm, mime-encodings
*** [strong] microcode/os2pm.scm, pm-procedures
*** [strong] runtime/http-syntax.scm, header-value-defns
*** [strong] ssp/mod-lisp.scm, mime-handlers
*** [strong] ssp/xhtml-expander.scm, *sabbr-table*

The processing instructions are processed incrementally as the file is
parsed, so keys in the sabbr table may be garbage-collected and then
re-interned, between which times the associations would be destroyed.

*** [strong] star-parser/matcher.scm, matcher-preprocessors
*** [strong] star-parser/matcher.scm, matcher-compilers
*** [strong] star-parser/parser.scm, parser-preprocessors
*** [strong] star-parser/parser.scm, parser-compilers
*** [strong] star-parser/shared.scm, make-parser-macros
*** [strong] star-parser/shared.scm, *global-parser-macros*
*** [strong] xdoc/validate-xdoc.scm, element-checkers
*** [strong] xdoc/xdoc.scm, html-generators
*** [strong] xdoc/xdoc.scm, when-conditions
*** [strong] xdoc/xdoc.scm, xdoc-content-types
*** [strong] xdoc/xdoc.scm, xdoc-element-types
*** [strong] xdoc/xdoc.scm, xdoc-input-canonicalizers
*** [strong] xdoc/xdoc.scm, xdoc-output-definitions
*** [strong] xml/xhtml.scm, element-context-map

** Other

*** [strong] compiler/machines/C/stackify.scm, stackify count tables

It is not immediately clear to me whether these need to be strong, but
they probably should be.

*** [strong] compiler/rtlbase/rtlobj.scm, label->object maps

It's not immediately obvious to me whether LABEL->OBJECT will ever be
used after the last references to the keys of the hash tables involved
(which cause strong references to those keys to be dropped, if
COMPILER:PRESERVE-DATA-STRUCTURES? is false).  A little further
analysis is required.  A conservative guess would be that these should
to be strong.

*** [weak] edwin/eystep.scm, ynode-regions

What are the keys to these hash tables?  I don't know how long they
persist.

Chris's answer: The keys are stepper nodes; they are stored in a text
property and consequently will be held appropriately.  This should be
a weak table.

*** [weak] edwin/prompt.scm, prompt-histories

Making this key-strong is not likely to be a space leak, but if a
command is garbage-collected, then so may the symbol for its history
be garbage-collected, and its history is presumably no longer needed.

*** [strong-eqv] edwin/win32.scm, event-handlers

The keys in EVENT-HANDLERS are integers.  I think this should be a
key-strong eqv hash table rather than a key-weak eq hash table.

*** [strong] edwin/xterm.scm, selection->record table in display/selection-records

I'm not sure what the domain of possible keys to this hash table is --
it may be just the symbols PRIMARY and CLIPBOARD, which will probably
be strongly referenced by the rest of the Edwin code, but on the other
hand I think this should probably be a key-strong hash table.

*** [strong] edwin/xterm.scm, symbol->x-atom table in display/cached-atoms-table

Whether this should be key-strong or key-weak depends on whether the
set of atoms that it will map is arbitrarily large.

*** [weak] imail/imail-core.scm, memoized-resources

As long as URLs are interned strongly, it doesn't matter whether
MEMOIZED-RESOURCES is key-weak or key-strong.  This requires further
analysis, but leaving it weak for now (i.e. not changing it) is safe
until internment of URLs changes.

*** [strong with comment] runtime/sfile.scm, interned-mime-types

This should really be a key-strong, datum-weak hash table, which the
hash table abstraction does not presently support.  (The same goes for
UNUSUAL-INTERNED-MIME-TYPES.)  Barring that, INTERNED-MIME-TYPES
should be key-strong, although it happens to work as a key-weak hash
table because its data have strong references to its keys anyway.

*** [weak] xdoc/xdoc.scm, *xdoc-element-properties*
*** [weak] xdoc/xdoc.scm, *xdoc-inputs*
*** [weak] xdoc/xdoc.scm, *xdoc-outputs*

As maps from XML elements by identity to properties, these three
should probably be key-weak, but since new ones are created for each
xdoc expansion, they could probably safely be key-strong without
badly leaking memory.

*** [strong] xdoc/xdoc.scm, *xdoc-id-map*

This should be key-strong, although it doesn't matter until XML names
become weakly interned.

*** [strong-eqv] xml/xhtml-entities.scm, table in html-char->name-map

The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
characters.  Should this be a key-strong eqv hash table rather than a
key-weak eq hash table?

*** [strong with comment] xml/xml-names.scm

If we had datum-weak hash tables, then EXPANDED-NAMES should be
key-weak and the other two should be datum-weak.  But we don't, so
instead all three should be strong, since in each one the data all
have strong references to their corresponding keys.