Raise ValueError instead of asserting ImageOps colorize() arguments

[LuShadowX]

ImageOps.colorize() checks its arguments with bare assert statements, which causes two problems.

Invalid arguments raise an AssertionError with no message, so nothing tells you which argument was wrong:

>>> ImageOps.colorize(im, "black", "white", blackpoint=200, whitepoint=50)
AssertionError

Under python -O the checks disappear entirely. Out-of-order points then reach the lookup table and fail with an internal message that says nothing about the arguments:

>>> ImageOps.colorize(im, "black", "white", blackpoint=200, whitepoint=50)
ValueError: wrong number of lut entries

A non-L image is the worst case: under -O there is no error at all, and the function returns an image without applying the intended wedge.

This raises ValueError with a message naming the argument at fault instead, the same way #9805 handled the assert in FtexImagePlugin.

The range of accepted values is unchanged. I compared the new conditions against the old asserts over boundary and out-of-range combinations of blackpoint/midpoint/whitepoint, and they agree on all of them.

Changes proposed in this pull request:

• Raise ValueError instead of asserting argument validity in ImageOps.colorize()
• Add tests for an invalid mode, invalid black/white points, and an invalid midpoint

[radarhere]

My personal preference would be for error messages that are expressed in natural words, but I don't have any ideas for how to do so while still being succinct.

[LuShadowX]

Thanks for the review and the wording PR — merged and much clearer than what I had. If there's anything else in ImageOps or the plugins you'd like a hand with, feel free to point me at it.