Most of the icons that are seen in the IDE during a standard Java editing
session are already painted via a call to Icon.paintIcon. One exception is the
separator icon that is used in the breadcrumb component under the code editor,
which is painted via Graphics.drawImage. Migrate this one to Icon.paintIcon to
make the icon look better on HiDPI displays (taking advantage of the HiDPI
scaling hints that were recently implemented in ImageUtilities).

This also serves as an example of how to fix other similar cases in the future.

…I icons

Introduced a FilteredIcon class which extends from a new CachedHiDPIIcon class.
The CachedHiDPIIcon class will be used again in the future; it was originally
designed for an SVG-based Icon implementation, which will be contributed
separately in the future. It is generic enough to work with any kind of custom
Icon implementation that needs caching.

Also make color filtering of icons for dark themes work with HiDPI icons, using
the same FilteredIcon class.

Also improved a null handling case in ImageUtilities.loadImage. Passing a null
resource used to be valid before (yielding a null return value), but caused a
NPE on dark LAFs. Since it worked in the common non-dark case, it should
arguably work in the dark case as well. This might fix NETBEANS-2401, or it
might just lead to an NPE elsewhere in that case.

…olTipImage is being passed around.

No public APIs are affected.

This commit prepares ImageUtilities to work with scalable Icon implementations,
such as a future SVGIcon class. Conversions such image2icon(icon2Image(icon))
are now lossless with respect to scalable Icon implementations. This allows
HiDPI support to be implemented via custom Icon classes while keeping existing
Image-based APIs (such as org.openide.nodes.Node.getIcon) unchanged.

The internal ImageUtilities.ToolTipImage class, which also implements the Icon
interface, is now used in most cases for ImageUtilities methods that return an
Image. Modifying ToolTipImage's paint() method to paint an extra debugging
stroke yields a quick confirmation that most of the icons visible in the IDE
now successfully have their painting delegated through this method. This will
come in handy in a subsequent commit, when we try to do some centralized scaling
improvements for HiDPI displays.

It is no longer safe to assume that ImageUtilities.image2Icon returns an
ImageIcon. Grepped the entire codebase for such casts (searched for cast to
ImageIcon within 3 lines of 'image2Icon'), and found only one, which was fixed.

Manually tested, including for the case where
ImageUtilities.getImageIconFilter() returns a non-null filter. Fixed a deadlock
bug that was unearthed in the latter case.

Having centralized icon painting into ImageUtilities.ToolTipImage.paintIcon in
the previous commits, we can now add a few painting tweaks to improve the
appearance of low-resolution bitmap icons that must be scaled up for HiDPI
displays. See the before/after screenshots that are attached to JIRA ticket
NETBEANS-2614.