[AC] Adjust load-path depth for modules

[Stephen J. Turnbull]

Michael Sperber writes:

 > I believe your Canna patch deleted a directory prefix from some module
 > name, right?  If so, your patch should go in.  (... and mine should
 > render Stephen's objection unnecessary)

I think that all this is true, but unfortunately I'm now running into
the "why is XEmacs looking for installed files?" problem, so I can't
yet say "works for me". :-(

`paths-find-module-directory' uses `paths-find-architecture-directory'.
Unfortunately, `paths-find-architecture-directory' does a breadth-
first search across roots, looking for architecture-specific
directories first, so it will definitely find
"/usr/local/xemacs/xemacs-21.5-b27/powerpc-apple-darwin8.8.0/modules"
before it finds "~/Software/XEmacs/git-staging/+build/modules" even
though I'm running in-place.

This seems very undesirable to me.  First, I would think that you'd
want an in-place XEmacs to try to find its associated files first.
This is especially true of modules, I would think, since we do not
have a published API for basic editor structures like buffers, and the
modules just #include the private headers.  I'm tempted to go so far
as to say that the pdump build-id should be in the module, and XEmacs
should refuse to load a module with a different build-id without user
interaction.  This is implementable; an in-place XEmacs can be
identified with near certainty from the presence of lib-src and tests
directories (among others) combined with the absence of the arch-
specific directory under the root.

Second, I would think that in general you want all of the various core
pieces to come from the same build.  Eg, when (as you and Aidan have
both recently done, in opposite directions) some function is moved
between C and Lisp.  While it seems likely (except for modules) that
things will work out that way, I don't see anything in the path-
finding code that tries to enforce it.