Issue title: Planned date for migration to Java 11
 Issue body: Premier support of Java 8 ends in March 2022:
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Non-LTS Java 9 and Java 10 aren't supported since 2018 and the next LTS release is 11.

State of our optional runtime dependencies:
- Lucene requires Java 11.
- JTS requires Java 8.

State of third-party DBMS / drivers used by some tests:
- Derby requires Java 9.
- HSQLDB has separate jars for 6, 8, and 11
- PgJDBC requires Java 8.

State of third-party projects that use or can use H2:
- Upcoming H2GIS 2.0 with H2 2.0 support requires Java 11.
- Upcoming Hibernate ORM 6 requires Java 11.
- jOOQ OSS Edition requires Java 11.

We need to define some date when our support of Java 8 will be discontinued. There are various places where it would be nice to use new APIs from Java 9 and newer versions. Now they can be used only with wrappers like our `Bits` and `Utils10` and different implementations for Java 8 and Java 9+ and I don't know should I add some additional methods or classes here or it will be more reasonable to wait for migration to Java 11.

@grandinj
@andreitokar
 Comments: 
 Comment 0: My 2c - Announce it on the mailing list, give it a few months so we can shake out some more of the bugs in the current version, then make the change to Java11
 Comment 1: We can create `version-2.0.x` branch and cherry-pick only significant bugfixes into it, such as recent fix for group-sorted optimization.

After about a couple of months we can release H2 2.0.206 from that branch with fixes only and Java 8 support.

When reasonable number of new features will be collected in the `master` branch we can release 2.1.210 with Java 11 support. By reasonable I mean not as many as we had in 1.9.197, 1.4.198, 1.4.200, and 2.0.202; they were too huge.
 Comment 2: As a user, I (selfishly) vote for Java 8 support for as long as possible
 Comment 3: H2 2.1 is going to be released with Java 8 support. Its patch releases, if any, will also have Java 8 support. This version doesn't have any significant new features, it's mostly an improved version of H2 2.0 with fixes for various regressions and some old issues. It has a good potential to become a stable version for Java 8 users.

But I think 2.2 should require Java 11. Most likely it will be released when premier support for Java 8 will have ended.
 Comment 4: I'd like to vote for longer Java 8 support, too. For example Amazon Corretto aims to provide security fixes for OpenJDK 8 until 2026: https://aws.amazon.com/de/corretto/faqs/, so I believe Java 8 will stick around for a bit longer. I work at Camunda where we embed h2 into our product and will continue to support Java 8 for a bit for these reasons and demand by our users. H2 moving to Java 11 would potentially prevent us from resolving vulnerabilities and critical bugs in h2. For example, trying to update from H2 1.4 to 2.x, I encountered https://github.com/h2database/h2database/issues/3414. As the fix will apparently only be part of H2 2.2 as I understand it, I'll have a bit of a problem if that version already doesn't support Java 8 anymore.
 Comment 5: Current `master` branch doesn't have any noticeable new features or incompatible changes. It means the next release in 2.1 series of releases can be made directly from this branch and it will include all these fixes for various regressions. I think we can do that in the near future, because users of H2 have some time to test it and report what they didn't expect. Security fixes, if any, can be backported to this series of releases in the future, I don't see any problems here.

But writing of a new code for Java 8 needs additional time, this version is very old and it doesn't have many nice features. In some cases a different code for Java 8 and newer versions can be required, because some features doesn't exist in Java 8 or can only be implemented in some alternative inefficient way. I don't have time for these complications. Do other contributors have? I don't know. H2 is not a commercial product, it is developed by a community.
 Comment 6: If people like @ThorbenLindhauer  want a Java8 branch, we can create a branch for that, and they are welcome to create PRs with the necessary backports, etc.

But I don't think any of the current committers have time or inclination for such a thing.
 Comment 7: Thanks for your quick response.

> Current master branch doesn't have any noticeable new features or incompatible changes. It means the next release in 2.1 series of releases can be made directly from this branch and it will include all these fixes for various regressions. I think we can do that in the near future, because users of H2 have some time to test it and report what they didn't expect. Security fixes, if any, can be backported to this series of releases in the future, I don't see any problems here.

It would be great if we could get another 2.1 release from current master before we move to 2.2. I saw the current snapshot version on master already being 2.2, so probably I misinterpreted that.

> But writing of a new code for Java 8 needs additional time, this version is very old and it doesn't have many nice features. In some cases a different code for Java 8 and newer versions can be required, because some features doesn't exist in Java 8 or can only be implemented in some alternative inefficient way. I don't have time for these complications. Do other contributors have? I don't know. H2 is not a commercial product, it is developed by a community.

I agree that this should be a decision of the core contributors and you should decide what works best for you. I just wanted to share my perspective as a user here.

> If people like @ThorbenLindhauer want a Java8 branch, we can create a branch for that, and they are welcome to create PRs with the necessary backports, etc.

If it becomes important for us, we might actually do this. So if the h2 core contributors are open to that, that would probably help us.
{'source': 'GithubIssues', 'repo_name_with_owner': 'h2database/h2database', 'issue_id': 1089196363, 'repo_stars': 3680.0}