More flexible validation in `sqllogictest`

### Is your feature request related to a problem or challenge?

When I am writing tests in #17319 :

In this test, it's intended to do a property check that the output includes 'HashJoinExec`. If such 'contains' check rule can be supported, such tests can be easier to maintain -- If the entire query plan is changed due to other modifications, we don't have to read the diff to verify if the change in this test case makes sense.
```
# Test that IS NOT DISTINCT FROM join produces HashJoin when used alone
query TT
EXPLAIN SELECT t1.id AS t1_id, t2.id AS t2_id, t1.val, t2.val
FROM t1
JOIN t2 ON t1.val IS NOT DISTINCT FROM t2.val
----
logical_plan
01)Projection: t1.id AS t1_id, t2.id AS t2_id, t1.val, t2.val
02)--Inner Join: t1.val = t2.val
03)----TableScan: t1 projection=[id, val]
04)----TableScan: t2 projection=[id, val]
physical_plan
01)ProjectionExec: expr=[id@0 as t1_id, id@2 as t2_id, val@1 as val, val@3 as val]
02)--CoalesceBatchesExec: target_batch_size=8192
03)----HashJoinExec: mode=CollectLeft, join_type=Inner, on=[(val@1, val@1)]
04)------DataSourceExec: partitions=1, partition_sizes=[1]
05)------DataSourceExec: partitions=1, partition_sizes=[1]
```

It can look like
```
# Test that IS NOT DISTINCT FROM join produces HashJoin when used alone
query TT
expect contains "HashJoinExec" <-- Here
EXPLAIN SELECT t1.id AS t1_id, t2.id AS t2_id, t1.val, t2.val
FROM t1
JOIN t2 ON t1.val IS NOT DISTINCT FROM t2.val
----
```

### Describe the solution you'd like

_No response_

- [ ] https://github.com/apache/datafusion/pull/18857
- [ ] Support 'contains' check
- [ ] Support 'regex' check

### Describe alternatives you've considered

_No response_

### Additional context

I don't know if `sqllogictest` already support a similar extension API for custom validations, if not this issue should be promoted to the upstream.

Start by reviewing the sqllogictest validation behavior and the context in issue #17319 and pull request #18857; the issue names no repository files or tests. Done means the described `expect contains` validation works for the shown EXPLAIN test, with the desired validation behavior confirmed against existing checks.

Written by the indexing model from the issue text.