Rewrite attachment storage backend

This was sort of how I implemented this a couple of months ago, but for
some reason I took a more integrated approach.  However, this approach
better allows future/further support of storage backends other than the
traditional IMP model (i.e. cloud storage).

Further, this approach better abstracts temporary storage vs. linked
storage. Since both appear the same to the user (the difference isn't
apparent until the message is sent out), they should be handled the same
by the code also.  Theoretically allows a backend driver to be written
that would store attachments differently based on content (e.g. images
get sent as linked attachment and saved in a web-accessible photo
application).

Instead of a hook, this can be configured by changing the $classAtc and
$classLink variables in IMP_Factory_ComposeAtc at run-time; this is a
bit too specialized for a hook, since it requires some knowledge of the
attachment storage classes before it can be implemented.