Shift responsibility for file associations to the installer

In the past, CiderPress managed its own file associations.  This is
the feature that launches CiderPress when you double-click on a ".shk"
file.  The installer ran "CiderPress -install" and "-uninstall" during
installation and removal to give CP a chance to establish and clean
up the necessary registry entries.

The code built with VS6 works fine.  The code built with VS2013 fails
with an access denied error.  It appears there have been some access
policy changes, and the older code is getting "grandfathered in".  This
is really something that the installer ought to be handling, though,
so rather than figure out how to fix CiderPress, I'm removing the
file type association code from CiderPress and letting DeployMaster
handle it.

This may be slightly less convenient for anyone who had reason to
change type associations frequently.  Modern versions of Windows have
relatively easy to use control panel UIs for adjusting types, and
the "advanced installation" feature of DeployMaster allows you to
un-check the types that you don't want to have associated with
CiderPress.

(...with one minor hitch: DeployMaster 4.2.2 only shows the first 9
associations, and CiderPress has 18.)

This change renders most of the registry-handling code obsolete, as
well as the "-install" / "-uninstall" handling.  I'm 99% sure I want
to go this way, but I'm keeping things #ifdefed rather than deleted
for the moment.