Take into account how the field is being used when determining cross-index field compatibility

Note: after HSEARCH-3399, it might seem that this problem is solved, but it is not. In particular the codecs only have one "isCompatibleWith" method that checks data related to multiple features (projections, sorts), and is called from the predicate/sort/projection factories despite being too coarse-grained.
See the comment starting with "Unrelated to your PR, but this is the kind of thing that makes isCompatible methods too coarse-grained" on this PR

Also note: we really need explicit tests for compatibility checks, preferably checking all possible combinations of types (string+string, string+date, date+date, date+integer, etc.), and checking all three DSLs (predicate, sort, projection). If possible, unit tests would probably be better, given the they are faster and we need to test many combinations.

TODO in this ticket:

• Split compatibility checks into multiple separate methods in codecs, so that each method checks for what's necessary and only that. We'll need at least two methods (one for predicate+sort, one for projection), but maybe more (one for predicate, one for sort, one for projection?)

• Improve the TCK tests of compatibility checks for projections. In particular, add a test where fields are compatible for projections, but not for predicates/sorts.

• Add TCK tests for compatibility checks for predicates (we only added a few for HSEARCH-3477, but they are not complete).

• Add TCK tests for compatibility checks for sorts

• Add tests for the isCompatible methods in the built-in value bridges of the POJO mapper. Maybe we can add something to FieldDefaultBridgeIT?

• Add tests for the isCompatible methods in the built-in id bridges of the POJO mapper.

• Make sure that error messages when two field types are incompatible will be clear to users. Currently I suspect we only display something like SomePredicateFactoryImpl@ea42432 to describe the type, which is not user-friendly, and on top of that doesn't provide all the necessary information.

—

Original description:

See https://github.com/hibernate/hibernate-search-6-poc/pull/93/files/1a8c67d4002e5642fcfd782dfad0468a6b45a088..6249c1bbd63ed870e8fa0b33e50e3572de235f9b#r214029552

In particular this:

Then, the isCompatibleWith method is really too coarse-grained. At some point we will need multiple ways to determine "compatibility" between indexes, because being compatible when projecting is not the same as being compatible when defining predicates, for example. Right now we just enforce the strictest (and most limiting) definition of "being compatible".