Work in progress MR as requested. See #90 (closed) and #304 (closed).

Notes/questions, copied from the issue:

• I've changed the inline_files and cid_files into Memory.Buffer instances but have left attached_files as File types for now. This was to get your feedback as also changing attached_files would mean changes through into Geary.Attachment (as a result of ComposerWidget's use through pending_attachments), which I presume will impact a bunch of other things. One of the downsides to not making this change are not being able to handle non-image dropped files as normal attachments.
• The way I've used get_uint8_array to build the GMime part (in RFC822.Message) feels like there should be a better way..?
• I'm using a hash of current time to build a filename for pasted images. Happy to hear other ideas.
• Currently I'm attempting to accept any dropped image with an image mime type (image/*). Are you happy to go with that for now or should we attempt to restrict to a few standard types?
• The blob:// URL scheme is required for dropping files into WebKit
• I've made some changes to ComposedEmail.replace_inline_img_src as the replaced term and search term can have the same length (which would have resulted in the previous test assuming and the replacement not succeeding). I do realise the updated approach is less performant (when the replacement succeeds).
• One minor usability issue I noticed is that when initially composing a new email the drop area for an inline image is pretty small as the WebKit view is only one line high

Thanks!

Also, I've just attempted to update from master but have some type of build environment issue (from Debian, GNOME, something changes?) that I don't have the time to resolve this second. Will need to get onto that.