No-arg MeanStdScaling constructor

[rofinn]

In many cases, we're gonna call apply with the same array data that was used to construct the MeanstdScaling transform, so why not provide a no-arg constructor and computing the mean and std on the fly in the apply call? I guess that would make the fields Union{Real, Nothing}.

[glennmoy]

@bencottier might also remember, but I think one reason we favoured immutable struct was to prevent the user from recycling the same scaling and potentially getting confused.

But I guess we could allow mutability iff the fields are nothing.

[bencottier]

@bencottier might also remember, but I think one reason we favoured immutable struct was to prevent the user from recycling the same scaling and potentially getting confused.

The other reason was saving code. We'd need to overload apply. This reason feels weaker than at the time of the original PR. In general I now feel more ok with overloading apply to add convenience. Also I think there'd be less overloading necessary after apply became the default (#25 ).

[AlexRobson]

A no-arg MeanStdScaling transform makes sense. We were just looking at swapping around transforms but at present, this means that we would need to handle the cases differently. e.g. comparing MeanStdScaling and LogTransform (recently added, but it applies to most (all?) other transforms that are not <:AbstractScaling)

function pipeline(x,...)
   ...
   transform = MeanStdScaling(x)
   ...
end

function pipeline(x,...)
   ...
   transform = LogTransform(x) # Would error
   ...
end

As @mzgubic points out, this requires separating out the constructor and the fitting