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.

No good reason not to put an explicit type on `seriesMean` and friends - basically though I just wanted to get a PR in for you to see and get a general thumbs-up / thumbs-down on the approach, before (rather laboriously) explicitly setting up dtypes for all these operations. Can certainly put that in. Agreed we want floats here... though having "count" as a float kind of makes me squirm... :)