Remove BundleActivator from org.eclipse.jface.text

[vogella]

Summary

The org.eclipse.jface.text BundleActivator existed only to lazily construct a single ExecutorService consumed by AsyncCompletionProposalPopup. The bundle context was never used, and there is exactly one internal caller of Activator.getExecutor().

This PR converts the class to a final holder with a static, lazily initialized executor (via the class‑holder idiom) and removes Bundle-Activator from the manifest.

• Activator.ID and Activator.getExecutor() are preserved, so the @since 3.29 public surface is unchanged.
• Worker threads remain daemon threads, so dropping the stop() shutdown hook has no JVM liveness impact.
• Bundle-ActivationPolicy: lazy is kept as is.

Motivation

Small reduction in BundleActivator usage across Platform UI. No observable startup time impact expected (the previous activator showed 0 ms in startup traces); the change is primarily a code‑quality and modernization step, intended as a template for similar trivial activators.

Test plan

• mvn clean verify -pl :org.eclipse.jface.text -Pbuild-individual-bundles passes.
• Content assist in the SDK still works, including async completion proposals (exercise AsyncCompletionProposalPopup).
• No API tools regressions (Activator.ID and Activator.getExecutor() remain available).

[github-actions]

Test Results

   852 files  ±0     852 suites  ±0   50m 31s ⏱️ - 8m 33s
 7 911 tests ±0   7 668 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 235 runs  ±0  19 580 ✅ ±0  655 💤 ±0  0 ❌ ±0 

Results for commit 71ef6f9. ± Comparison against base commit b7b54fc.

♻️ This comment has been updated with latest results.

[laeubi]

The executor is now never shut down.

[laeubi]

@vogella please review and validate AI generated (I assume it is) code prior to submission!
It is your responsibility as a committer to be certain a given thing is actually valid, the missing shutdown is an obvious bug also the PR title is confusing (as it does not really removes the activator). Using of the "class‑holder idiom" is complete over-engineering here and as it is only used in one place it then would be much more suitable to move the code here than to retain a confusing Activator class that is not actually one anymore.

Also looking at the git-history would have revealed that the activator has a purpose, that is ensure proper cleanup of the executor.

[vogella]

My main concern here is that the Activator is exposed as API, hence abandan the PR