Enable unit-testing of designdoc functions using CommonJS

The documented Couchdb support for CommonJS makes it difficult to author functions for map, reduce, update etc. which use shared code and which can **_both_** be
* evaluated **_within NodeJS_** in a test suite
...and...
* evaluated **_within Couchdb_** in a design doc

This can be addressed with a minor improvement to `require()` behaviour, or by documenting support if there is in fact some way to do this.

## Summary

I have succeeded at putting together unit testing of a map function in NodeJS, followed by component testing of the resulting view in Couchdb.

However, I face the restriction that all functions have to be monolithic (not use require), since I can't get any script using require to work _both_ locally in the filesystem for unit testing _and_ remotely in couchdb for component testing because of restrictions on `require()` paths. This makes it hard to maintain the codebase of my view functions.

## Possible Solutions

This issue could be addressed by a change to the CommonJS `require()` feature to add relative paths, or potentially by improved documentation.

### Solution: Documenting How

If there is already some way to achieve scripts which can have requires which are consistent for both local _and_ remote imports, this could be documented to assist in test-driven development of Spidermonkey functions.

### Solution: Making `require()` resolve relative paths

Allowing relatively-addressed CommonJS `require()` paths (instead of requires all being rooted in the global namespace at "view/lib" ) would make it straightforward to define locally-run scripts-and-requires which directly mirror the server-side scripts-and-requires, simply by placing the source files in a directory hierarchy which mirrors the designdoc JSON tree hierarchy.

The [Couchdb CommonJS documentation](https://docs.couchdb.org/en/stable/query-server/javascript.html#commonjs-modules) states all requireable modules must be addressed as modules in the globally-rooted namespace with a "view/lib" prefix like `require("view/lib/mymodule")`. This prevents the use of modules with relative paths such as `require("../lib/mymodule")` from within a view map function.

With support for relative paths, locally-developed scripts would be able to evaluate properly in Node for unit-testing.

## Additional Context

For reference, I am including gists with testing code from a private repo.
* See an example map function: https://gist.github.com/cefn/48da2af998922817e8f2459c9461840f
* See example unit and component tests for the map function: https://gist.github.com/cefn/5ec24e4f1c04afecd3fd133426ea36bb
* See example script 'Loader' which makes map function loadable and testable in Node https://gist.github.com/cefn/ac18aeb00b4e67afa2043a8f0b8ca6fa
* See example script 'CouchdbConfigurator' which pushes the functions to a view running within a temporary Couch db for component testing: https://gist.github.com/cefn/8ef16aa522c208d4d2877f2d40359a45

Start with the CouchDB CommonJS modules documentation and the linked example map, unit-test, component-test, Loader, and CouchdbConfigurator scripts. Determine whether relative require paths can support both NodeJS and CouchDB execution, and whether the issue should result in documentation or a CommonJS behavior change; done requires a clearly defined, tested approach.

Written by the indexing model from the issue text.