WIP: faster low level modules

[nstarman]

Proof of concept.
Results in 21x speedup in BoundMethod initialization, translating into 14x speedup of method access from a Module.
This is stacked on top of speedups associated with #1220.

In quax I was doing some line profiling and found that some examples in the tests had 2k method accesses, making this a non-trivial slowdown when considering a whole code pipeline.

---

This PR introduces a lower-level meta class and base class which internal Modules like BoundMethod can use, that bypasses the Module.__call__, and Module.__getattribte__. This is a WIP since there are details to be worked out, like:

1. if instead it would be better to add a flag on Module that skips these slow methods, consolidating back to one class.
2. if _AbstractModule should implement a from-style __setattr__, etc.

But I do think something should be done, since creating a BoundMethod on every method access is a common operation and is relatively slow, evidenced by this 14x performance improvement.

The main issue is the mildly(?) user-facing change

class MyModule(eqx.Module):
    a: int

    def f(self, b):
        return self.a + b

m = MyModule(13)
assert isinstance(m.f, eqx.Module)  # fails
assert isinstance(m.f, eqx.AbstractModule)  # if `_AbstractModule` is made public as `AbstractModule`

[nstarman]

@patrick-kidger what do you think of this potential fast-path for low-level Modules?

[patrick-kidger]

I think a __call__ fastpath would make sense, but rather than making it a separate class then I think we could arrange to have it be enabled automatically: for example, we don't need to check that fields are initialised if the class uses the dataclass-generated default; we can skip all the checks if all of the tuples are in the common case of being empty.

Ultimately I definitely don't want a new class – as you note it's user-visible, but more than that it's simply past the complexity/speed tradeoff for would consider valuable. It's important to me that Equinox be easy to maintain.

[nstarman]

See #1230