Resolve #345: Make icons customizable

[a-leithner]

This aims to provide a first implementation of an abstraction that could be used to customize the icons used in ICEpdf's Swing components when using them in embedding applications (i.e. fixes #345).

Some key points of the changes:

• The icon pack to be used will be loaded from Swing's UIManager using the key org.icepdf.iconpack. I took this idea from FlatLaF, its defaults can be customized this way. Technically, it should be possible to ship ICEpdf with mutliple icon packs and let the user choose their preferred one (like LibreOffice does), though I don't see a benefit investing the time right now since we only have one default pack currently.
• Though the icon pack is (dynamically) loaded from UIManager, the respective key has to be set before the first use of Images as this class will cache the icon pack in a static final field; therefore, once Images gets initialized, the icon pack cannot be changed (this is to provide consistency across the UI).
• Icon packs can freely choose the concrete pixel values for the five available icon sizes.
• Icon packs can freely choose the subset of variants they provide (e.g. FlatLaF's FlatSVGIcon, which could well be returned by a user's icon pack, automatically creates disabled icons, so these icon packs wouldn't need to set separate icons).
• The implementation of the default icon pack fails with a NPE if the requested icon could not be found.
• All places previously dealing with ImageIcon directly have been modified to only depend on Icon, as not all Icons which could be returned by icon packs have to be ImageIcons.
• The few GIF icons have been converted to PNG to be able to load them via the default icon pack.
• Icon size preferences will be preserved, but will be upgraded to use the IconSize enum upon next update.
• It is now a responsibility of the Images utility class to apply all available icon variations to a button when applying a specific icon (previously, we were manually retrieving and applying the rollover, disabled, ... variations of a button's icon everywhere we were creating buttons – this has been changed to a single call into Images, which takes the current icon pack's capability into account).
• Images takes care of retrieving the correct default icon size from user's preferences now as well.
• ImageColorIcon should probably be renamed to reflect it no longer depends on an ImageIcon.

I'm more than happy to discuss all changes and design decisions I made here. Especially the move of ImageColorIcon from extends ImageIcon to implements Icon and using composition rather than inheritance is something I'd like to hear opinions on. Also, I've placed a TODO in the constructor of AbstractColorButton, since I'm unsure if we can/should change the code calculating the preferred size the way I did (I'm also unsure of why we're changing the preferred size this way – shouldn't that component and most others calling setPreferredSize actually override getPreferredSize?).

[pcorless]

Thank you for for putting this together. I've started working my way though it.

[pcorless]

Thanks for the updates, I'll give it more look over but suspect it's ready to go.