Explicitly allow to use Comparison and Composite in JOIN conditions

[phansys]

These changes explicitly allow to use Comparison and Composite in JOIN conditions.
This is currently possible, but in an implicit way, since the values are silently converted to string as both classes are implementing the __toString() method.
After these changes, PHPStan findings like this, can be resolved:

Parameter #4 $condition of method Doctrine\ORM\QueryBuilder::join() expects string|null, Doctrine\ORM\Query\Expr\Andx given.

[greg0ire]

Where does the conversion happen?
How do we know these classes are the only 2 possibilities?
I suppose you have considered using Stringable and rejected it?

[phansys]

Where does the conversion happen?

Join::__toString():

orm/lib/Doctrine/ORM/Query/Expr/Join.php

Lines 125 to 131 in 833d981

	public function __toString()
	{
	return strtoupper($this->joinType) . ' JOIN ' . $this->join
	. ($this->alias ? ' ' . $this->alias : '')
	. ($this->indexBy ? ' INDEX BY ' . $this->indexBy : '')
	. ($this->condition ? ' ' . strtoupper($this->conditionType) . ' ' . $this->condition : '');
	}

How do we know these classes are the only 2 possibilities?

I don't know if there are more possibilities. These cases are what I have in my projects.
I guess we could add more cases if needed.

I suppose you have considered using Stringable and rejected it?

I considered this possibility, but as we might prefer to narrow the possibilities to classes we trust near its string representation, I decided to use them individually.

[derrabus]

Suggested change

	* @return string|Comparison|Composite
	* @return string|Comparison|Composite|null

Seems like nullability is not documented correctly on any of the getters. Or am I missing something?

[phansys]

Yes, that seems right IMO.
I didn't include this type because the same situation is present in other properties ($alias, $conditionType, $indexBy).
I think we should make a separate PR for these cases, as I suspect this is not the only class affected by this issue.
WDYT?