Allow concat_batches to work with RecordBatches that have different metadata

[alamb]

Which issue does this PR close?

Resolves #4799

Rationale for this change

See Resolves #4799

What changes are included in this PR?

1. Only check datatype and field name when verifying compatibility -- ignore other details like metadata
2. Tests for same

Are there any user-facing changes?

concat will not error in as many cases

[tustvold]

Is this not correct behaviour? If the metadata is inconsistent how does it know which metadata to preserve?

[tustvold]

This seems similar to https://docs.rs/arrow-schema/latest/arrow_schema/struct.Schema.html#method.contains

[alamb]

If the metadata is inconsistent how does it know which metadata to preserve?

Right now the Schema of the output RecordBatch is the schema that was provided by the caller as the first argument to concat_batches

To summarize a conversation I had with @tustvold over slack

1. I believe his core concern with this PR is that making this check more lax means that it is likely papering over what some people might perceive as a bug in the caller (in this case, inconsistent metadata)

2. An alternative interpretation might be that by checking for exactly the same schema for all input batches, the concat_batches kernel is imposing a particular definition of schema equality and enforcing an invariant that might not be what other systems have in mind. From this point of view, removing the Schema equality check entirely might be appropriate

I am sure I can fix my particular problem (see https://github.com/influxdata/influxdb_iox/pull/8691/files#r1319044861) other level of the stack (e.g in DataFusion) but it didn't feel right to me that concat_batches was enforcing some particular invariant that is not enforced elsewhere

[alamb]

See discussion on #4801

[alamb]

Conclusion of the discussion I think is that we would prefer to remove the error checking entirely. See #4815