Reconsider storing constructors internally

[DonutEspresso]

Custom constructors created via makeConstructor() are currently stored on the module. This can create some problems if this module is shared between libraries that want to create constructors with the same name (or happens to get deduped by npm/yarn). There is an argument to be made that returning the constructor to userland, where users can keep track of it themselves, is the simplest path forward. While that increases friction in terms of usability, it also increases flexibility.

We could explore options for a hybrid approaches, as well.

[simonepri]

Maybe we could add something like an optional 'namespace' while creating a new Constructor?
For me it makes sense to leave users the handling of custom error constructors. Maybe we could move that feature to an external package to reduce the friction.

Talking about usability we should also rethink themakeErrFromCode function.
The absence of the new keyword makes the error creation incoherent and may generate confusions.

The syntax should be something like:

new errors.HttpCode(httpCode, /* Any argument combination available for other errors constructors */);

or something like that:

const Err = errors.errFromCode(code);
new Err(/* arguments */);
// or shorter:
new errors.errFromCode(code)(/* arguments */);

[DonutEspresso]

As suggested in this thread, custom error constructors are now returned directly to end user. This is effective starting in 6.x.