GH-89987: Shrink the BINARY_SUBSCR caches

[brandtbucher]

BINARY_SUBSCR has 3 cache entries that are only used by BINARY_SUBSCR_GETITEM (a type version and a function version). However, we don't really need to store all of this information per call-site... we can just keep the function version on the type (next to the cached method) and clear the cached method whenever the type is modified.

Besides the savings in code size, this has a couple of other minor benefits:

• Any BINARY_SUBSCR_GETITEM site can work with any heap type defining __getitem__, provided it's already been cached at least once somewhere.
• We can specialize for more than 65k function versions.

Performance is neutral.

• Issue: Remove C stack use by specializing BINARY_SUBSCR, STORE_SUBSCR, LOAD_ATTR, and STORE_ATTR #89987

[markshannon]

I'm a bit concerned about ABA errors.
For example:

1. Site X is specialized for some version of class C and C.getitem.
2. Then C.getitem is modified
3. Site Y is specialized, setting the cached version to the new function.
4. Now site X runs again.

Is this OK?

I think it is, but it requires a different contract between the specializer, the specialized code and the class's cache, than we had before.

This contract will need to be clearly documented.
Does this seem correct:

• If the _specialization_cache.getitem field is non-NULL, then the value it holds is what PyType_Lookup(cls, "__getitem__") would return.
• If _specialization_cache.getitem is NULL, the getitem_version field is meaningless.
• If the _specialization_cache.getitem field is non-NULL and _specialization_cache.getitem_version == _specialization_cache.getitem->func_version then _specialization_cache.getitem is a Python function that can be called with two positional arguments and no keyword arguments, and has neither *args nor **kwargs.

[brandtbucher]

Yes, that's correct. I'll document this clearly in a comment.