Fix IconService architecture

[ctrueden]

The IconService exists to make it possible to paint icons in a UI-agnostic way. Unfortunately, the current architecture has some problems:

1. There is no default or dummy IconService implementation. So if something depends on IconService, but does not include another dependency with an actual concrete implementation, then it will not be possible to create an ImageJ context with an IconService. We avoid this issue in other cases by having a dummy service (e.g., with RenderingService) that performs no-ops.
2. The architecture needs more consideration and testing with respect to UIs besides Swing, with multiple UIs, and when running without a UI. Right now, if you create a headless ImageJ context, the SwingIconService is still used for icon drawing, when it may not be the most appropriate solution. It may be simpler to integrate the icon drawing logic into the UIService and/or UserInterface interfaces more directly. Regardless, further thought is needed.

Migrated-From: http://trac.imagej.net/ticket/1627