RegExpMacroAssembler::GetCode returns a Handle<Object>. However, that
Handle is almost immediately dereferenced, and is stored as a bare
Object in both RegExpCompiler::CompilationResult and RegExpCompileData.

This makes SpiderMonkey's rooting hazard analysis somewhat
antsy. While RegExpCompileData is alive on the stack, the hazard
analysis will not allow any calls that might GC, because it isn't
smart enough to prove that the code field can't be clobbered by a GC.

As far as I can tell, there is no real hazard here, but storing a
Handle in RegExpCompileData instead of a bare Object will simplify SM
and prevent a future patch from accidentally breaking something.

Bug: v8:10406
Change-Id: I9642dd05c591bfd23b340a89df2f2bf5c9fcac2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161578Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67441}