Far and Remotable do unverified local marking rather than WeakMap

[erights]

Far and Remotable still splice an object into the inheritance chain, but now that object also contains a symbol-named property marking the object as a remotable. Unlike the WeakMap, this is not a reliable brand, so passStyleOf must validate it each time.

Corrected for a previous misunderstanding of Object.entries. I thought it did all enumerable own properties, like .... Actually it only does string-named enumerable own properties. I avoid it when that restriction is inappropriate.

The marshal package no longer exports mustPassByRemote or mustPassByPresence. Instead, clients should use passStyleOf.

I limited Remotable to the current usage pattern: The props must be undefined. The remotable if provided must inherit from null or Object.prototype. The inheritance restriction propagates to Far.

[erights]

Ready for review!

@michaelfig Please look at the changes to the wallet test. If they are correct now, were they not correct before? If so, I'm unclear on why it was not working before this PR.

[michaelfig]

@michaelfig Please look at the changes to the wallet test. If they are correct now, were they not correct before?

They were correct before, modulo the fact that the test was using the fakeVatAdmin. That entailed separate import namespaces for the contract and the test, and hence separate getInterface WeakMaps, but without a marshal boundary between the two of them.

So, ZCF's makeHandle('Invitation') did not affect the test's WeakMap and so its interface name was lost. The test relied on that behaviour.

If so, I'm unclear on why it was not working before this PR.

[Assuming you meant "why it was working".]

@dtribble and I had figured out how to test contracts with actual marshal layers between them. I think that would have made the test always behave as you expect.

[michaelfig]

LGTM. I reviewed all the changes, since I had some familiarity with the plan to proceed with them.