Instead of having a loop with one big switch for handling the different
opcodes, split the decoding into one handler per opcode and call them
via an opcode handler table.
The compiler will generate similar code for this new approach (the big
switch is also compiled into a table lookup and an indirect jump). The
main difference is that it's now calls instead of jumps. This has a
slight performance impact, but allows to look at the decoding logic of
individual opcodes in isolation and see optimization opportunities much
easier. It also allows spot very easily in profilers on which opcodes
most time is spent.

The different opcode handlers are still implemented via the same switch
as before, but since the opcode is a template argument (hence static)
the compiler will eliminate the switch and generate the small handlers
we want.
I plan to actually remove the switch and break up the big generic
{DecodeOp} method into one method per opcode.

R=thibaudm@chromium.org

Bug: v8:10576
Change-Id: Ic2c1e2fe5e98df52a7079ace305cf77340dcbf35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249664Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68403}