fix multiple usages of regexp-exec

[Khartir]

Closes #751

I would have liked to add a test for this, but I have honestly no idea of how to do so.

[zloirock]

I need some time to explore this issue deeper.

[zloirock]

core-js should be maximally modular and es.regexp.exec module should work without es.regexp.constructor or es.regexp.sticky.

[zloirock]

I'm confused in this code. @nicolo-ribaudo could you say something about #751, #754, #810?

[Khartir]

@zloirock As far as I can tell, the problem with making es.regexp.exec, es.regexp.constructor and es.regexp.sticky independent of each other is that in order to support the y flag all have to be modified: the constructor to accept the flag, sticky to add the property and exec to actually handle it.

So maybe the solution should be to combine the modules into one? The only way to split this cleanly in different packages would probably be to have a sticky package that would modify constructor, property and exec all on its own and have the other packages only do what they did before. That would require overwriting the constructor and exec multiple times (in the correct order) and would still not solve #751 because this comparison would still fail.

[zloirock]

@Khartir too many other modules depend on es.regexp.exec, we should not enforce load es.regexp.constructor and es.regexp.sticky to modules that depend on it. So we should fix it without uniting those modules.

[zloirock]

I'll replace the check of regexpExec to RegExp.prototype.exec in maybeCallNative as a temporal fix - it will fix this issue, but RegExp -> String logic should be completely reworked.