streamline OrdinalMarginLoss construction

[Evizero]

Since we ended up not doing the unrolling, it seems more flexible to not make N a type var. This way its cleaner for N to depend on the data.

Aside from this, I wrote the constructor of OrdinalMarginLoss such that its easy to define clean typealiases.

For example the following is possible:

const OrdinalHingeLoss = OrdinalMarginLoss{HingeLoss}
OrdinalHingeLoss(5) # N=5

Since HingeLoss has no free parameters the above is quite simple, but the construction even works for all MarginLoss that do have free paramaters, such as the SmoothedL1HingeLoss

julia> const OrdinalSmoothedHingeLoss = OrdinalMarginLoss{<:SmoothedL1HingeLoss};

julia> OrdinalSmoothedHingeLoss(5, 2.1)
OrdinalMarginLoss{SmoothedL1HingeLoss{Float64}}(SmoothedL1HingeLoss{Float64}(2.1), 4)

cc: @mihirparadkar

[mihirparadkar]

That seems like a good idea for ease-of-use. My one possible concern with removing the type parameter is that the compiler may have been unrolling the loop already but can't anymore, but this doesn't seem like a big deal for a small number of levels.

[Evizero]

but this doesn't seem like a big deal for a small number of levels.

The thing is if it doesn't really help with for a small loop, it is unlikely to help with a large one.

Regardless, I am far from opposed to changing it back at some point if some benchmarks show its benefit. All I really aim for here is to not make any non-trivial optimization that didn't show promise.
And without the unrolling there is currently no upside to having the number of levels in the type