Turn bindings into zero-cost

[Kingdutch]

This makes a few API breaking changes and removes some of the Functor magic in favor of duplication. The result is that the test bindings themselves become slightly more verbose in tests but are also zero-cost.

This fixes an issue where Vitest would complain that it was imported from a dependency of the test which causes the set-up to be performed multiple times:

Error: Vitest was initialized with native Node instead of Vite Node.

One of the following is possible:
- "vitest" is imported outside of your tests (in that case, use "vitest/node" or import.meta.vitest)
- "vitest" is imported inside "globalSetup" (use "setupFiles", because "globalSetup" runs in a different context)
- Your dependency inside "node_modules" imports "vitest" directly (in that case, inline that dependency, using "deps.inline" config)
- Otherwise, it might be a Vitest bug. Please report it to https://github.com/vitest-dev/vitest/issues

[cometkim]

@Kingdutch Can you provide minimal suite that reproduce the bug?

[Kingdutch]

@cometkim I looked at doing that but I think this triggered on "- Your dependency inside "node_modules" imports "vitest" directly (in that case, inline that dependency, using "deps.inline" config)" which is hard to reproduce within a single repository.

I've set-up https://github.com/Kingdutch/vitest-reproduction which copies your basic.test.res, has only added rescript and rescript-vitest and just runs build and test which immediately hits the error.

I did forget to set-up a gitignore so there's some fluff in there but I hope the problem is reproducible this way :D

[cometkim]

Hey @Kingdutch, thanks for taking your time on this.

This approach seems only valid when using an implicitly exposed global Vitest context. (that's usually enough)

However, I will take a different approach in the future to support all the various features of Vitest. As a result, the API may be more verbose, but the issues you report will be resolved.