Support for dtype-next's export-symbols

[daslu]

The dtype-next library by @cnuernber, which is the foundation of a high-performance data stack in Clojure, offers a certain way to export symbols from one namespace to another. https://github.com/cnuernber/dtype-next/blob/4e1256/src/tech/v3/datatype/export_symbols.clj

This is used in the main API namespace of several libraries, in addition to dtype-next itself. Some of these libraries are:

• tech.ml.dataset by @cnuernber
• tablecloth by @generateme
• metamorph.ml by @behrica
• scicloj.ml by @behrica

See for example the main tablecloth.api namespace: https://github.com/scicloj/tablecloth/blob/c7b6a04/src/tablecloth/api.clj

This way, vars are generated at runtime. Thus in static code analysis, important symbols are not known to be bound to anything in these API namespaces. This affects warnings, autocomplete, etc.

@otfrom has been looking into this in the context of other static analysis tools, such as clj-kondo and clojure-lsp, and may possibly say more about it -- see this discussion: https://clojurians.zulipchat.com/#narrow/stream/151924-data-science/topic/clj-kondo.2C.20clojure-lsp.2C.20tablecloth.2C.20and.20others

Even though there is a general discussion of problems of this kind at #147, maybe this case deserves an issue of its own, since it is relevant to the usability of several libraries, and seems to be solvable by some ad-hod handling of this specific macro.

[daslu]

This might be useful:

A solution for handling export-symbols in clj-kondo was given by @otfrom here: https://github.com/cnuernber/dtype-next/pull/45

[daslu]

This has been solved for dtype-next and tech.ml.dataset using code generation.

Zulip announcement by @cnuernber: https://clojurians.zulipchat.com/#narrow/stream/151924-data-science/topic/tech.2Eml.2Edataset/near/264019964