AsyncIterator.from returns an AsyncFromSyncIterator-record

[Jamesernator]

In the current spec text the AsyncIterator.from method when given a sync iterator currently does:

ii. Return ! CreateAsyncFromSyncIterator(syncIteratorRecord).

But, in the ECMA262 spec the CreateAsyncFromSyncIterator doesn't create an iterator at all, it creates an iterator record.

Now the fix here is pretty trivial, just capture the value and return iteratorRecord.[[Iterator]] like elsewhere.

However, there is the question as to whether or not we want to be exposing AsyncFromSyncIterator objects at all. Currently AsyncFromSyncIterator is really just a spec fiction to enable iterating sync iterators in async iteration contexts, in this regard we may not want to expose the object itself, but rather re-wrap with an outer AsyncIterator.

Although perhaps we do want to expose such objects, in which case are we comfortable with AsyncIterator.from returning a "subclass"? Although it does happen in Web APIs, returning "subclasses" isn't something that happens at present in ECMA262 APIs*, it may also go against some OO principles but this fairly debatable.

* NOTE TypedArray methods are called from their concrete subclasses, not as say TypedArray.from or the like

[Jamesernator]

Actually this is a dup of #159 , although I will open a separate issue on the meta-issue of exposing AsyncFromSyncIterator.