Fix join on arrays of unhashable types and allow hash join on all types supported at run-time

[findepi]

Which issue does this PR close?

None

Rationale for this change

fix potential query failure due to incorrect can_hash result

What changes are included in this PR?

• update can_hash
• cleanup compute_hashes

Are these changes tested?

Yes, unit tests.
query-based tests are hard to write -- it is unclear how to construct Union or RunEndEncoded types in SQL

Are there any user-facing changes?

yes

[alamb]

query-based tests are hard to write -- it is unclear how to construct Union or RunEndEncoded types in SQL

One way to do so would be via arrow_cast

However, those types don't seem to be supported via arrow_cast yet:

> select arrow_cast(1, 'Union(Union))');
Error during planning: Unsupported type 'Union(Union))'. Must be a supported arrow type name such as 'Int32' or 'Timestamp(Nanosecond, None)'. Error unrecognized word: Union

[alamb]

The other way to do it is to programatically setup the sqllogictest, as is done for map.slt (which didn't have any way to create MapArrays when it was written):

datafusion/datafusion/sqllogictest/src/test_context.rs

Lines 84 to 85 in ac79ef3

	}
	"map.slt" => {

[alamb]

Converting to draft as I think it is waiting on some tests. Please let me know if that isn't right and this is ready for another review

[findepi]

This change has two aspects

1. fixing hash joins on types that are not hashable, but can_hash considered them hashable. This is eg List of something unhashable. I couldn't write a test for this, since types such as listview or ree hit other problems.
2. unblocking hash joins on types that are actually hashable, but can_hash considered them not hashable. This is not as edge-case'y, for example binary is hashable, but we didn't use hash joins when joining on binary. I added a plan test for this.