fix incorrect propagation of dtype in Series normalize and other methods

This PR addresses a bug in `Series.normalize()` and other methods, where the `dtype` attribute of the output was being set incorrectly to the `dtype` of the input RDD.

After this patch, the default behavior for `apply()` and most other methods that can potentially produce output with a dtype different from the input will be to leave this attribute unset, to be lazily determined  as needed by making an implicit call to `first()` when the `dtype` attribute is requested.

For `normalize()` in particular, the output dtype will now be the smallest floating-point type that can safely store the data without over/underflow, as determined by `commons.smallest_float_type()`. This will be properly set on the output Series, so that no implicit `first()` call is needed.

@freeman-lab, if you're okay with this PR, I can take care of merging it into master from the 0.4.x branch.

Not sure I follow? The awkward syntax there was in order to control the output type of the division, by providing an explicit output array. Otherwise we'd get out float64s which we'd then have to manually downcast to float32s or whatever our desired float type is, in which case our peak memory consumption is still that of a float64 array.