Support user-provided JQ modules

[goedelsoup]

Is your feature request related to a problem? Please describe.

I frequently have to replicate filters between numerous Weaver configurations in order to support providing our customers with a consistent SDK across languages. It would be great to consolidate the filtering logic alongside my registry definitions and templates.

Describe the solution you'd like

Forge currently loads a default module while provides the helper functions authors would typically use for their template generation. It would be great if we could supply additional modules to load via the weaver generate command.

Describe alternatives you've considered

Many warts encountered when dealing with deprecated elements could be worked around by adding a exclude_attribute and exclude_metric option on the relevant functions, however, user-defined JQ modules would provide better composition long-term under the multi-registry support model.

[lquerel]

Supporting the addition of a JQ prelude alongside the one already in place doesn’t seem very complicated. We could leverage 1) the existing override mechanism used for building the weaver.yaml configuration (see this doc), and 2) the introduction of a new field in the WeaverConfig structure that allows adding one or more JQ prelude files. This would enable the predefined prelude to be supplemented with one or more custom JQ preludes shared across multiple template directories.

Question: Would you prefer to have the option to completely bypass the default JQ prelude, or would the ability to add additional preludes be sufficient?

If someone is interested in implementing this request, I can provide more details.

[goedelsoup]

My initial idea was just to be able to supply modules in addition to the prelude, as they utilize some of the prelude functions. I personally don't see any reasonable need to exclude the prelude; even in scenarios where one may want to lint/validate that only certain functions were used, I'd imagine that'd be a positive assertion.