feat(Learner): support marshal property

[sebffischer]

Suggestion:

• Per default, when calling benchmark() or resample(), the models are in unmarshaled form.
• When calling $score() and $aggregate() it is checked whether the measure needs access to the model, and if so, a good error message is given that informs the user that: a) He needs to $unmarshal() the object b) After doing so, he needs to $marshal() again to be able to save the object

TODOs:

• we can save one cycle when using callr encapsulation + parallelization by not discarding the marshalled model before the predict step.
• talk about the cloning issue (see https://github.com/HenrikBengtsson/marshal/issues/12)

Points for discussion:

• package versioning: It would be useful to store the most important package versions when marshaling, as it will otherwise become tricky to unmarshal the object later. Henrik's approach is to store the unmarshal function in the marshaled object: https://github.com/HenrikBengtsson/marshal/blob/72e976c61f00861ceb0b4c0c0fd7016b4eee417a/R/marshal.default.R#L30 and it is then the obligation of the unmarshal function to do the version checking.

This is useful for learners that e.g. rely on external pointers and that need processing of the model to be serializable. Addresses https://github.com/mlr-org/mlr3/issues/891

Input checks on the measure (check that model is not marshaleld when accessing the model) only work partially (https://github.com/mlr-org/mlr3/issues/1000)

• mlr3tuning: https://github.com/mlr-org/mlr3tuning/pull/410
• mlr3batchmark: https://github.com/mlr-org/mlr3batchmark/pull/28
• mlr3pipelines https://github.com/mlr-org/mlr3pipelines/pull/759

TODOs:

• [ ] Gallery Post

[sebffischer]

Related PR in mlr3torch: https://github.com/mlr-org/mlr3torch/pull/179

[sebffischer]

• $bundle() and $unbundle() should only be implemented in the Learners that actually implement them.