Conversion to sequence<T> need not throw on a RegExp object

[rniwa]

When an ECMAScript value V is converted to an IDL sequence value, we don't really need to throw a TypeError when V is a nativeRegExp object.

Ordinarily, a RegExp object wouldn't have Symbol.iterator defined. If it's defined, e.g. x = new RegExp; x[Symbol.iterator] = function* () { yield 1; }, then we should be able to iterate over it.

[domenic]

In general I find the way the Web IDL spec treats RegExp and Date objects specially rather strange... Maybe there is historical context I am missing.

[bzbarsky]

The historical context is twofold:

1. The intent was to make Date and RegExp distinguishable from dictionaries and sequences during overload resolution.
2. At one point the intent was that adding an overload should generally not change which overload got invoked for previously-accepted values. That meant that an overload accepting dictionary or sequence should not accept RegExp or Date. The idea was to avoid forward-compat bugs in APIs where behavior would change for existing callers when a new overload was added.

I think we've already deviated that principle in item 2 when we made dictionary and sequence distinguishable while still allowing iterables to represent dictionaries. And I, personally, don't think it's a big deal to drop that principle entirely.

That said, for the specific case of RegExp, I think removing it entirely as #148 suggests is the right way to go.