Bazel: Add EE8 servlet bridge targets

Add Bazel-only generated EE8 targets for the HTTP servlet and LFS
server modules. The generated jars keep the original JGit Java
packages and rewrite only servlet API references from jakarta.servlet
to javax.servlet.

The rewrite uses the shared servlet-flavour transform toolchain from
bazlets (transform_srcjar + generated_srcs_test.sh under //tools). It
is a plain sed package-prefix substitution; the universal servlet and
Jetty package mapping lives in bazlets and this consumer selects only
the direction (to_javax), so it carries no renames data and adds no
Maven dependency (no Eclipse Transformer CLI).

This supports source consumers that still run on EE8 while JGit master
uses Jakarta servlet APIs. Gerrit is the known downstream consumer in
that state today and consumes JGit from source through a git submodule.
With these targets, Gerrit can track JGit master without a dedicated
servlet-4 maintenance branch.

The goal is to let the servlet-4 branch be retired for Gerrit's
maintenance purposes. That branch was not offered as a stable JGit
release line. Keeping Gerrit on it makes JGit updates hard for Gerrit,
including updates for important fixes and improvements, and forces
repeated merge work from master onto a parallel branch.

Keep the maintenance surface small. The EE8 targets consume canonical
srcs filegroups backed by glob(["src/**/*.java"]), so new Java sources
flow into the generated jars without per-file BUILD updates. Resources
are also shared through canonical filegroups.

This Bazel change intentionally does not add Maven, Tycho/p2, or Maven
Central publication machinery. Maven support is added by the follow-up
Maven commit; Tycho/p2 remains out of scope because the EE8 jars export
the same packages as their canonical Jakarta counterparts and are not
co-installable with them.

Also avoid relocating Java packages to org.eclipse.jgit.*.ee8. Keeping
the same package names avoids source-consumer import churn, but means
the canonical Jakarta jars and generated EE8 jars must not share a
classpath.

Possible follow-ups are duplicate-classpath enforcement for source
consumers and additional generated EE8 modules only when a consumer
needs them.

Verify generated source layout, line counts, javax servlet rewriting,
and the absence of package-renamed .ee8 sources.

Change-Id: I897e4facbbae79349e8d1853ea4dab8d7087ba5b