using hashes for internal URLs

[Per Bothner]

When using the js-info reader, the location bar displays these URLs for nodes:
  https://domterm.org/Wire-byte-protocol.html (if http/https)
  file:///home/bothner/DomTerm/web/index.html#Wire-byte-protocol (if file:)
These are also what you get if you right-click a link and select "Copy link".

(The reason for the difference if using file: scheme has to do with browser
security restrictions.)

"Inner" URL have the form:
  https://domterm.org/Wire-byte-protocol.html#Window-operations (if 
http:/https:)
  
file:///home/bothner/DomTerm/web/index.html#Wire-byte-protocol.Window-operations
 (if file:)

I suggest an option (perhaps the default) to always prefer the #hash form.
So the public link might be:
  https://domterm.org#Wire-byte-protocol
Most servers would treat the following as equivalent to the above:
  https://domterm.org/#Wire-byte-protocol
  https://domterm.org/index.html#Wire-byte-protocol

So far this makes for slightly shorter URLs, as well as consistency
when using file: URL. The big win comes if we do the same for
inner URLs.  So the Window-operations link becomes:
  https://domterm.org#Window-operations

This requires a mapping table generated by tex2any so info.js can
translate #Window-operations to Wire-byte-protocol.html#Window-operations.
This table should include *all* @node names *and* @anchor names.
This would allow links to remain valid even if things are moved
around. I think this makes for a nicer solution than using
redirection pages.

To handle the case when JavaScript is missing/disabled, we can
make the re-mapping table human-readable. Perhaps:

<li id="Window-operations"><p>
For ``Window operations'' see <a 
href="Wire-byte-protocol.html#Window-operations">here</a>.
</p></li>

Then using the URL with the hash #Window-operations takes to a line
with an easy-to-click link to the correct file and position.
The re-mapping table would be hidden if using JavaScript.
--
        --Per Bothner
per@bothner.com   http://per.bothner.com/