Enhance performance evaluations

[ablaom]

This PR provides a few enhancements for the results of evaluate or evaluate!, which estimate
various kinds of out-of-sample performance of MLJ models (resp., machines). These should make evaluate more convenient when applying it to batches of models, to be compared:

• The estimate of standard errors, which is currently only calculated for display of a
  returned object, is now calculated when the object is constructed, and is a new,
  user-accessible property, uncertainty_radius_95.

• Users can now "tag" their estimates, by doing evaluate("some tag" => model, ...)
  instead of evaluate(model, ...) and the returned object has a new user-accessible
  property tag for storing this. Tags are auto-generated using the model name when not supplied,
  but for deeply wrapped models, this is often inadequate, hence the addition of user
  tags. The tag is shown when the object is displayed.

• Users can now evaluate a vector of models, or tagged models, as in the following
  example, where we can see the user-supplied tags in the output:

evaluate(["const" => ConstantClassifier(), "knn" => KNNClassifier()], X , y)
# 2-element Vector{...}
#  PerformanceEvaluation("const", 0.698 ± 0.0062)
#  PerformanceEvaluation("knn", 2.22e-16 ± 0.0)

Similar changes apply to the evaluate!(::Machine, ...) form.

In the future we might add a summarize(evaluations) to convert the kind of information displayed here in a table.

I found a few corner-case bugs in the display of performance evaluation objects, which I
have fixed. I have also added a lot more testing of the display, and added examples to the
docstrings for evaluate and evaluate!.

This PR closes #1031.

[ablaom]

cc @LucasMatSP @mohdibntarek

[LucasMatSP]

Nice feature!

[ablaom]

In the vector case, perhaps we should just parallelize with multiple threads by default. It's just serial for now. @OkonSamuel What do you think?

[OkonSamuel]

Is there any reason we are allowing Machines to be passed here. I say this because of the type <:Union{Machine,Pair{String,<:Model}} I thought this would have been <:Union{Model,Pair{String,<:Model}}

[ablaom]

Good catch. This is a mistake. I'll fix and add a test.

[OkonSamuel]

In the vector case, perhaps we should just parallelize with multiple threads by default. It's just serial for now. @OkonSamuel What do you think?

If we did this we will encounter some issues. For example we might have a data race. I don't think anything prevents someone from doing this

mach1 = machine(ConstantClassifier(), X, y)
evaluate!(["const1" => mach1, "const2" => mach1])

But if we ran this on the same thread, we will be modifying the same machine object from different threads which could lead to race issue.

Although this shouldn't be an issue if we just use the regular evaluate method and if the models run of different datasets, this is perfect. The only problem here is if the model runs on the same dataset, then we will have different copies of the same dataset (No?).

[ablaom]

What if we just throw an error if there are duplicate machines? Would it suffice to test with === ?

Although this shouldn't be an issue if we just use the regular evaluate method and if the models run of different datasets, this is perfect. The only problem here is if the model runs on the same dataset, then we will have different copies of the same dataset (No?).

Binding a machine to data does not duplicate the data, as far as I can tell. However, there is at least one MLJ operation that I can think of that mutates data, such as coerce!(::DataFrame, ...), and there's nothing stopping a user from putting her own data-mutating operations in a pipeline model. There may be others in MLJTransforms.jl that might be mutating for certain table types (OneHotEncoding, for example??); I suspect not, but we should look into this and remedy if necessary. As a general principle, we should probably disallow mutation of the data consumed by fit, predict or transform. If it's needed internally, a copy will have to made. I mean, we already have parallelism in MLJTuning that would lead to race conditions for these kind of data-mutating operations. Mmm...

[ablaom]

@OkonSamuel I think we just leave out the parallelism for now.

Are you happy for me to merge?

[OkonSamuel]

Yes @ablaom we should leave out parallelism for now. Asides that I'm happy for this to be merged.

[ablaom]

@OkonSamuel Thank you for your review and helpful feedback.