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 DESIGN: clone / inplace argument futureverse/marshal#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:/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 #891

Input checks on the measure (check that model is not marshaleld when accessing the model) only work partially (#1000)

• mlr3tuning: feat: add marshalling mlr3tuning#410
• mlr3batchmark: add marshalling mlr3batchmark#28
• mlr3pipelines support marshaling in GraphLearner mlr3pipelines#759

TODOs:

• Gallery Post

[sebffischer]

Related PR in mlr3torch:
mlr-org/mlr3torch#179

[sebffischer]

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