Avoid calling DSL.nullSafe() and similar all over the DSL API, move the calls to QueryPart constructors

[lukaseder]

All over the jOOQ API, we have DSL.nullSafe() and related calls that make sure that bind values are wrapped with the appropriate data type when writing things like this:

INT_COLUMN.eq(1);
CONVERTED_COLUMN.eq(new Something(...));

While we could guess that the value 1 is really just the same as DSL.val(1), in the second case, we cannot make any data type guesses. We have to use the type of CONVERTED_COLUMN. We can see, in AbstractField:

    @Override
    public final Condition equal(T value) {
        return equal(Tools.field(value, this));
    }

    @Override
    public final Condition equal(Field<T> field) {
        return compare(EQUALS, nullSafe(field, getDataType()));
    }

Both of these methods wrap the value using this.getDataType() information. It is being done twice, and then again in the compare() method:

    @Override
    public final Condition compare(Comparator comparator, Field<T> field) {
        switch (comparator) {
            case IS_DISTINCT_FROM:
            case IS_NOT_DISTINCT_FROM:
                return new IsDistinctFrom<>(this, nullSafe(field, getDataType()), comparator);

            default:
                return new CompareCondition(this, nullSafe(field, getDataType()), comparator);
        }
    }

And starting with jOOQ 3.15.0 also in the CompareCondition constructor because of the requirements here #11061:

    CompareCondition(Field<?> field1, Field<?> field2, Comparator comparator) {
        this.field1 = nullSafe(field1, field2.getDataType());
        this.field2 = nullSafe(field2, field1.getDataType());
        this.comparator = comparator;
    }

Doing all of this in the constructor has these benefits:

• It is always the last call, so if we can delay wrapping and converting things, we will still be guaranteed of the conversion to happen
• It is the most reasonable location where both expressions can be wrapped. Historically, we could convert types correctly when writing CONVERTED_COLUMN.eq(x), but not when writing val(x).eq(CONVERTED_COLUMN). This will be required by Parser should look up data types for bind variables from context #11061, and will now be possible when moving this logic into the constructors.

[lukaseder]

A caveat of this change is that some constructor arguments are optional. When null they represent the absence of the argument, not the null bind value. This implementation detail shouldn't leak into the API, and users may have come to rely on a null field argument meaning null the bind value.

[lukaseder]

This issue will be fixed step by step as an epic task along with #11061, #11070, #11091

[lukaseder]

There will be more improvements in this area, which will be done via #11061 and #11070, implicitly