Add the Faker connector

[nineinchnick]

Description

The purpose of this connector would be similar to tpch/tpcds - generate random data to be used for all kinds of testing. The main difference is that this works with all Trino data types and any kind of schema. It's also using the Datafaker library, which allows generating more sophisticated random data in multiple languages.

For more details, including usage examples, see https://github.com/nineinchnick/trino-faker/

I'll add documentation if the general idea of adding this connector will be approved.

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
(x) Release notes are required, with the following suggested text:

## Faker
* Add Faker connector to allow easy generation of data for testing. ({issue}`23691`)

[nineinchnick]

@raunaqmorarka thanks a lot for the review, everything looks much nicer now!

[mosabua]

Personally I think this would be a great and very useful connector to add. It would enable numerous use cases around learning Trino, testing, benchmarking and other efforts. Specifically it also goes beyond the rather narrow and stale setup from TPCH/TPCDS.

[raunaqmorarka]

Ideally what we want is

generator.accept(blockBuilder, completedRows, positions);

Generate N positions in a batch.
This is a megamorphic call site, so looping over it per position can be slow

[nineinchnick]

I don't know what's a megamorphic call site, can you share some references? This would change the interfaces a lot, and I'm not confident I can do this correctly, without understanding the optimization. Is this a blocker for this PR?

[nineinchnick]

BTW I was benchmarking it like this, comparing to the sequence table function, and it was fast enough. I'm not sure what gains we can expect here.

[raunaqmorarka]

The short version is that when you have a method call that can be dispatched to more than 2 possible implementations, the JIT may not do certain optimizations and the code may end up being much slower than what it would have been had there been just 1 or 2 possible implementations.
Longer version in http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/
To observe the perf impact, you have to execute this code for 3 different data types and compare the throughput with what you would get if you only executed it on one data type.
This can be tackled in a follow-up, not important enough for current PR to tackle.

[raunaqmorarka]

generateRandom ?

[raunaqmorarka]

@nineinchnick please work with @mosabua to update docs for this