Fixes #1451 and #1407 by standardizing the maximum width for bitmaps that we are adding to spans in the editor.

* Made all ImageHelper methods static.
* Changed `getMaximumThumbnailWidth()` in EditPostContentFragment to accommodate for 48dp of padding on each side, instead of where it was being calculated in ImageHelper.getThumbnailForWPImageSpan(). This allows ImageHelper.getScaledBitmapAtLongestSide to also use this to resize to the proper dimensions. This ensures that all bitmaps we are adding to the editor will be the correct size.
* Removed getThumbnailWidth() method since it is no longer needed.
Merge branch 'develop' into issue/1451-media-thumbnail-width
Pass the scaled bitmap through getScaledBitmapAtLongestSide() in case we need to resize for portrait orientation.
Fixes issue where rotation was incorrect for local image in post preview and editor.
Changed visibility of content textView to visible, so we can get its width.
ViewPostFragment now waits until mContentTextView has been laid out, so we can get its width and pass it to WPHtml.fromHtml()
WPHtml now accepts a maxImageWidth parameter, so that images can be properly sized when using fromHtml()
Base the max image width on the smallest dimension of the fragment's view.

Fixes issue where image could be too large if you rotated from landscape to portrait in the post view.

Also added AsyncTasks for loading local post content in EditPostContentFragment as well as EditPostPreviewFragment as they were blocking the UI thread.
Wrap fragment_edit_post_preview layout in a ScrollView so that the TextView can be scrolled if the content is larger than the view.
Made mMaxImageWidth not static, otherwise other threads could modify its value and cause unexpected results.
Merge pull request #1460 from wordpress-mobile/issue/1451-media-thumbnail-width

Issue/1451 media thumbnail width