Mitigate security issues with custom ALTREP vectors

[MarcusKlik]

When an ALTREP vector is de-serialized, custom code is executed in the UnserializeEX client method. That code can contain anything so can be be potentially harmful.

Normally, R's de-serialization mechanism runs the appropriate UnserializeEX method from the R package that originally serialized the ALTREP vector. That means that without that package present on the user's system, an error will result and no custom code will be executed (that's relatively safe).

But lazyvec allows for the definition and serialization of custom users methods. This introduces a possible security risk. It's possible (and easy) to engineer a rds file that looks and feels like a comparable non-ALTREP rds file, but contains harmful code. If the user has lazyvec installed, that harmful code can be executed without the user noticing.

This is clearly undesirable, a solution might be:

1. lazyvec allows reading rds files with custom code only when a certain option is set, e.g. lazyvec_dev_mode = TRUE. If the option is not set, only option 2 is allowed.
2. lazyvec only runs custom code that is defined in a package. This mechanism mimics the mechanism used in R's ALTREP framework.

With option 2, reading an rds from unknown source is as safe as the packages that the user has installed on the system. Most end-users won't ever need option 1.

During development of a custom lazyvec implementation package, option 1 can be used to (temporarily) allow directly running custom methods.