Convert unknown rank image to 4D image

[facaiy]

Fix #243

1. The name *_4D_image looks kind of confusing, any good idea?
2. I didn't check all image ops and see if they can work well with unknown rank image, perhaps we should file a new issue with check list.

[kyleabeauchamp]

Overall this looks good and is a nice cleanup of the image code. My only question before merging is whether we need to be more explicit about what assumptions we're making regarding the input shape. E.g., do we need to say in docstrings that we explicitly support (N, H, W, C), (H, W, C), and (H, W) inputs and assume that channel (if present) is last? Maybe we can assume the user knows some of this, but it might be good to be explicit in the docstrings.

[WindQAQ]

Generally LGTM. Thank you, Facai! May related to #320 (docstring)

[facaiy]

@kyleabeauchamp Good question, Kyle, I didn't notice that. I think *_4D_image methods work for both channel-last and channel-first format, so I revise the corresponding code comments. And for rotate, transform methods, they are designed only for channel-last format which has been written in the corresponding documents.

@WindQAQ It's wired that I find all tests pass without tf.control_dependencies. For safety, I have add the op as suggested :-)

All comments has been solved, can you take a look again, Kyle and Tzu-Wei?

[WindQAQ]

@facaiy thank you! @kyleabeauchamp, Kyle, feel free to merge this after taking a look.

[facaiy]

Forget to mention: *_4D_image and get_ndims are only visible in the image module by now, namely, they are not public endpoint of addons.

[kyleabeauchamp]

LGTM