[FLINK-39183][table] Support BITMAP type in Calcite parser

[dylanhz]

What is the purpose of the change

This pull request adds parsing support for the BITMAP data type in Flink's Calcite-based SQL parser.

Brief change log

• Added BITMAP token and type literal to Parser.jj
• Extended the forked SqlTypeName and SqlTypeFamily enums with BITMAP

Verifying this change

• FlinkSqlParserImplTest#testBitmapType

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? not documented (documentation will be added when the full BITMAP type support is complete)

[flinkbot]

CI report:

• bdf482d Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[snuyanzin]

is it in Calcite?
We shouldn't change this file without good justification
It should be removed once we bump to certain Calcite version

[snuyanzin]

Can we do this without Parser.jj modification?
Or first be sure it is merged to Calcite and then port changes here

[liuyongvs]

Can we do this without Parser.jj modification? Or first be sure it is merged to Calcite and then port changes here

i also agree this "merged to Calcite and then port changes here"

[dylanhz]

Can we do this without Parser.jj modification? Or first be sure it is merged to Calcite and then port changes here

Thanks for the review!

BITMAP is not a SQL standard type — it's an extension type specific to analytical systems, so proposing it to Calcite upstream doesn't really make sense. This also shouldn't block Flink from introducing its own extension type.

For the Parser.jj concern, would it be acceptable if we move the token and type parsing rule into Parser.tdd and parserImpls.ftl? This follows the same pattern used by STRING, BYTES, RAW, etc. The SqlTypeName.java and SqlTypeFamily.java changes would remain as-is.