[CQ] remove experimental BadgeIcon dependency

[pq]

The class com.intellij.ui.BadgeIcon is marked @experimental and is flagged by the verifier:

  Experimental API usages (4): 
      #Experimental API class com.intellij.ui.BadgeIcon reference
          Experimental API class com.intellij.ui.BadgeIcon is referenced in io.flutter.toolwindow.ToolWindowBadgeUpdater.lambda$updateBadgedIcon$1(ToolWindow) : void. This class can be changed in a future release leading to incompatibilities
          Experimental API class com.intellij.ui.BadgeIcon is referenced in io.flutter.toolwindow.ToolWindowBadgeUpdater.lambda$updateBadgedIcon$0(ToolWindow) : void. This class can be changed in a future release leading to incompatibilities
      #Experimental API constructor com.intellij.ui.BadgeIcon.<init>(Icon, Paint) invocation
          Experimental API constructor com.intellij.ui.BadgeIcon.<init>(javax.swing.Icon icon, java.awt.Paint paint) is invoked in io.flutter.toolwindow.ToolWindowBadgeUpdater.lambda$updateBadgedIcon$1(ToolWindow) : void. This constructor can be changed in a future release leading to incompatibilities
          Experimental API constructor com.intellij.ui.BadgeIcon.<init>(javax.swing.Icon icon, java.awt.Paint paint) is invoked in io.flutter.toolwindow.ToolWindowBadgeUpdater.lambda$updateBadgedIcon$0(ToolWindow) : void. This constructor can be changed in a future release leading to incompatibilities

This change introduces a lightweight replacement, allowing us to remove the dependency and enable VerifyPluginTask.FailureLevel.EXPERIMENTAL_API_USAGES failure checking in the verifier (see: #8361).

---

Behavior is preserved w/ the replacement:

Default:

with badge:

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our [contributor guide](https://github.com/dart-lang/sdk/blob/main/CONTRIBUTING.md for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Dart contributions to our repos should follow the Dart style guide and use dart format.
• Java and Kotlin contributions should strive to follow Java and Kotlin best practices (discussion).

[helin24]

I was under the impression that we avoid * imports, but I'm not sure if that's enforced somewhere in java settings.

[pq]

Interesting! This is what the IDE did on-save. Doing a quick grep I see we've got 104+ * imports in 74+ files so we're definitely not consistently avoiding them.

That could be this inspection?

https://www.jetbrains.com/help/inspectopedia/OnDemandImport.html

Happy to discuss enabling!

[helin24]

A quick search suggests to me it is better to avoid * imports (avoids potential naming conflicts, avoids indexing classes that aren't needed). Is enabling the inspection something we do individually or can we save it to the repository?

[pq]

Thinking a bit about it, I tend to agree. Wildcard imports are probably best to avoid. Could you add some discussion to #8098?

We do have a checked in inspection set and think we should probably enable it there but we should discuss. It would also be great to get the inspections run in the CI, if not as part of the verifier, as a separate task. I've poked at that a bit but got distracted. (Some info here: https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-profiles.)