Allow OVERRIDE wrappers to chain.

[ruipin]

The module "Better Rolls" has an interesting use case. It is, by default, a full override. As such, it uses "OVERRIDE". However, if the caller passes a specific parameter, it wishes to call the original method.

Because OVERRIDE by default doesn't provide the wrapped chain object, they are forced to use private APIs to access the _wrapped method instead. In addition to being unsupported, this will soon become impossible due to the work for https://github.com/ruipin/fvtt-lib-wrapper/issues/16.

In the original API design, OVERRIDE didn't provide the wrapped chain object on purpose. This was to avoid people using OVERRIDE just because they wanted to be the last module called, even when they weren't truly overriding a method. However, I failed to realise that there is a very rare use case where such a module might wish to call the original method.

An optional solution that does not compromise the API's design goals and maintains backward compatibility is to take an optional chain parameter that, if true, provides the wrapped chain object regardless of the wrapper type:

libWrapper.register("module-a", "Foo.prototype.bar", "OVERRIDE", {chain: true});

Optionally, the third parameter could be replaced by the dictionary (only when not a string, for backwards compatibility), e.g.:

libWrapper.register("module-a", "Foo.prototype.bar", {type: "OVERRIDE", chain: true});

[ruipin]

v1.3.6.0 implements the first syntax:

libWrapper.register("module-a", "Foo.prototype.bar", "OVERRIDE", {chain: true});

I chose the first syntax to avoid needing messy backwards compatibility code.

Same change also adds a test for this syntax. This API is not documented yet, pending Better Rolls using it, in case we need to change it. It will be considered public soon.

[ruipin]

Reopening just to track the Better Rolls updates, and update the documentation.

[ruipin]

This is now documented in v1.4.0.0, and Better Rolls has been updated.

Closing.