LoadFileAsNewImage: reduce the need for manually counting colors...

...to determine incoming color depth.  We can retrieve this data from
GDI+, and while it may not be accurate, it at least allows us to match
the incoming color depth if the corresponding preference is set.
pdInputMouse: separate mouse and keyboard handling into two classes

The reasons for this are long and involved, but basically, I'm starting
work on various frameworks required for drawing tools.  This requires a
number of architectural improvements to pdInput.  Keyboard and mouse
handling have proven to be totally different beasts, and as the existing
pdInput class is already a mess, I don't want to complicate it further.
Moving mouse and key handling into separate classes will allow me to
more easily (and reliably) deal with the nuances of each.

This initial commit does not touch the existing pdInput class at all.
It simply contains a new, "minimal" pdInputMouse class, which contains
just the mouse bits from the existing pdInput class.

Next, I'll be converting various PD dialogs and user controls to
pdInputMouse, if they don't require specialized key handling.  When that
is complete, I'll move the keyboard bits from pdInput into a new
pdInputKeyboard class, then kill off the existing pdInput class.
Convert all mouse-only instances of pdInput to pdInputMouse
pdCanvas: make sure scroll bars are hidden when all images are unloaded
pdInputKeyboard: dedicated keyboard input handler now ready

See 3b08cdaf0f93dd9892fe505bf83d551fbf268d81 for additional commentary
Convert remaining pdInput instances to pdInputMouse and/or pdInputKeyboard

Program will once again compile and save, but I should add a a WARNING
that keyboard input may be wonky until I have time for additional
testing on this new solution.