Use Remote<T> to indicate tolerance of far types

[michaelfig]

What is the Problem Being Solved?

The state-of-the-art typing used in Agoric SDK to indicate potentially remote presences is:

1. ERef<T> only indicates that T may or may not be a promise. The downside is after await T, is performed, there is no propagation of the remote nature of T.
2. FarRef<T> is a more complex type that attempts to express promise-or-not, awaitable local properties, and a remote brand check, but without propagation.

It would be useful to have a type designation (Remote<T>) for an object created by Far or an exo, which says that a function producing or consuming such a type will (by default) treat it as potentially remote.

Description of the Design

Now that RemotableBrand has been supported for a long time in @endo/eventual-send, and has been added to Far, Remotable, and zone.exo*, we can use it. This will build more sophisticated remote typing than ERef<T> and clearer than FarRef<T>.

With care, Remote<T> can be used in any situation, conserving information as a function argument or return value, as well as a variable or in a data structure.

Security Considerations

Improves correctness when handling remote objects.

Scaling Considerations

Encourages synchronous calls to be converted to async, which introduces more turns. For performance-sensitive code running in the same vat as a remotable such as Remote<{ getNum(): number }>, if a locality assertion like 'getNum' in remotable is true, remotable will be narrowed to a synchronous callable (such that remotable.getNum() is possible).

Test Plan

Use Remote<T> in existing code and verify that Typescript only points out problems to solve that are understandable consequences of the new typing.

Upgrade Considerations

Types are erased, so there is no runtime impact on code that uses Remote<T>.