fakeDurable feature should be guarded by a kernel config option

[FUDCo]

What is the Problem Being Solved?

The fakeDurable feature recently provided by #5481 is intended only for use at development time. In particular, no production swingset should be running with vats containing fake durable collections or DVOs, as these are guaranteed to explode horribly in the event of any upgrade attempt, including a null upgrade.

Description of the Design

By requiring a swingset configuration option governing the availability of the fakeDurable option, we can ensure that any attempt to use this feature in a production context will fail. However, the "fake durable" concept per se is deeply entangled with the virtual objects and stores abstractions, which are part of liveslots rather than swingset itself. Having a top-level configuration option at the kernel level specifically for this feature would be an inappropriate blurring of abstraction boundaries since the kernel itself knows nothing of the durable object abstractions. On the other hand, despite the abstraction boundary issue, it does make sense to govern this feature globally rather than making it a vat creation option, since we would not wish the feature to be available to any vat at all in operational contexts where it would be inappropriate for the feature to be used.

I propose instead that the swingset configuration have a generalized development mode flag whose value would be available to liveslots (or to any other vat-specific runtime that we might someday add), which would in turn be allowed to interpret this flag however it felt appropriate. Liveslots would use flag this to regulate availability of the fakeDurable option, but I can imagine other development-time features being regulated by this flag, potentially in conjunction with vat-specific options, all in the service of code development.

I propose to add a global configuration option, devMode, which would be a boolean flag configured at the same level as defaultManagerType or defaultReapInterval are now. This would be passed along to liveslots as part of its initial configuration parameters.

Security Considerations

I don't believe this feature introduces any specific new security concerns; rather, its addition would plug a potential security hole that might otherwise result if ill-behaved vats were to make use of fakeDurable in a production context.

[FUDCo]

@warner