Proposal: record-tuple-polyfill

Babel recently introduced a support for the Record and Tuple ECMAScript proposal. Babel currently uses [`@bloomberg/record-tuple-polyfill`](https://github.com/bloomberg/record-tuple-polyfill/tree/master/packages/record-tuple-polyfill) as the underling implementation. But I was wondering how this compares to `@wry/record` and `@wry/tuple` and wether they would be usable as an alternative polyfill?

I'm favoring `@wry/record` and `@wry/tuple` from an implementation perspective. Correct me if I'm wrong, but `@bloomberg/record-tuple-polyfill` seems to be unnecessary complex and convoluted in comparison.
I'd like to propose a new package `@wry/record-tuple-polyfill` if semantic-, API- and formal compatibility are given.

(Non exhaustive) list of requirements for this proposed package:
1. re-exports of `Tuple` from `@wry/tuple` and `Record` from `@wry/record`
2. additional tests to ensure _formal_, _semantic_ and _API_ compatibility with `@bloomberg/record-tuple-polyfill`
3. _(stretch goal or pre-condition?)_ a benchmark suite (that also covers memory consumption)

Requirement 1. should be trivial to do. It will be something like this:
```ts
export Record from "@wry/record";
export Tuple from "@wry/tuple";

```
Meeting the second requirement might be a little bit more tricky. I think a property based testing approach could give the strongest guarantees here.

Not sure if the benchmark suite should be rather a precondition for publishing the new package or if is a rather a stretch goal.

**(any input/discussion is very appreciated)**

Start by comparing @wry/record and @wry/tuple with @bloomberg/record-tuple-polyfill for formal, semantic, and API compatibility. Review the proposed re-exports, then assess the property-based compatibility tests and optional benchmark suite; the work is done when the package requirements and publishing decision are resolved.

Written by the indexing model from the issue text.