Adopt lazy loading model for module imports

[joewiz]

What is the problem

As described by @adamretter in the 2018-03-19 Community Call:

For every query, we compile every module loaded in conf.xml. Modules like the file module are already bound. Even if you haven’t bound it in your query, it’s already bound. This is inefficient, slows things down, and prevents users from supplying their own binding to the EXPath File Module.

See also https://github.com/eXist-db/expath-file-module/issues/6, in which the only way to import the EXPath File Module is to comment out the native file module in conf.xml and restart eXist, but having done this, there is no way to use the native file module.

The solution proposed by @adamretter is to move to "lazy loading" of modules.

What did you expect

I expected to be able to freely override default module namespace prefix bindings set in conf.xml.

Describe how to reproduce or add a test

1. Install the EXPath File Module xar (built via directions in the README.md file at https://github.com/eXist-db/expath-file-module)
2. Execute the following query:

   inspect:inspect-module-uri(xs:anyURI("http://expath.org/ns/file"))

3. Currently, this query produces an error, instead of return a representation of the EXPath File Module. The error:

   err:XQST0033 Cannot bind prefix 'file' to 'http://expath.org/ns/file' it is already bound to 'http://exist-db.org/xquery/file' [source: xquery version "3.1"; inspect:inspect-module-uri(xs:anyURI("http://expath.org/ns/file"))]

Context information

• eXist-db version + Git Revision hash: eXist 4.2.0-SNAPSHOT develop e63daf7f0
• Java version: 1.8.0_162-b12
• Operating system: macOS 10.13.4
• 32 or 64 bit: 64 bit
• Any custom changes in e.g. conf.xml: none

[duncdrum]

My only concern is that as an XQuery processor eXist is right to define pre-assigned module namespaces, which users should not be able to freely override. Just as you cannot simple define your own xml:custom namespace or point xml:lang to some other location. Users would need to come up with better namespaces for their modules in case of clashes. So by lazy-loading we might end-up enabling something that we shouldn't.

[duncdrum]

see #1771