More flexibility in function targetting

One of the strengths of xgettext-js is that it does one thing well, namely finding functions that match a pattern.

However, javascript moves fast, and there are some odd issues that have cropped up and will likely continue to crop up.

For example, pr #6 addresses an issue caused by an odd quirk in transpiling es6 module syntax in babel. This is a very specific and temporary problem, and arguably does not belong in xgettext-js. Luckily, the solution for is benign enough that there's very little downside to including the fix in xgettext-js itself, but we might not be so lucky in the future.

What we need to avoid this problem in the future is something to allow us to intervene before the matching logic does it's work.

There are a range of options trading off flexibility for complexity. #6 would have been solvable with a relatively simple hook to preprocess just the CallExpression itself before xgettext-js tries to match against it, which might be a good place to start.

Hooks like that could also be used for some pretty cool things, like composable filters - if the node matches some criteria, don't pass it on.

This is all pretty low priority speculation that should probably be driven by real needs rather than "just in case". We don't actually have a use case for filtering right now, for example. It would be cool, but not useful.

Review PR #6 and the existing CallExpression matching logic first, focusing on where preprocessing could occur. The issue does not name files or tests and explicitly describes filtering as speculative; completion would require a concrete use case and an agreed hook design before implementation.

Written by the indexing model from the issue text.