dbg: avoid hardcoded enums

Besides reducing lines of code this way the extension becomes compatible
with various versions of LuaJIT because different versions might use
different sets of enum members (a newer version might introduce
additional BC/IR/etc.)

Prior to this patch, the string was used as a debugger-agnostic way to
specify type, but this way might not work in the case of an enum because
debugging information might be optimized out if no variable of such an
enum type is declared and its members are used only as predefined
constants. The type of enum is needed to be able to get human-readable
value (member name instead of number). The alternative way to get enum
type is to get it from the value, i.e. somehow obtain the value that is
of enum type and then use this type to convert the numbers to the member
names.

Creating the value of the given enum member is quite different in GDB
and LLDB, so separate method `create_enum_value` was introduced in
Debugger API. Also new method `cast_typeof` was introduced to perform
value-based cast, i.e. it casts to the same type as a reference value.

Also this patch fixes the mapping of FPMATHOP to a human-readable form,
because prior to this patch, IRFPMS contained the incorrect entry
'exp2'. IRFPMS is a human-readable form of enum IRFPMathOp, but there is
no 'exp2' enum member actually (see IRFPMDEF). It looks like it was
added by mistake initially (corresponding tests to check mapping of
FPMATHOP were added).

Other adjustments:
* [gdb] in 'eval' method dropped check of the value returned by
  gdb.parse_and_eval() as it would fail also for expression like '0',
  i.e. affects all the involved enums (looks like a kind of experimental
  code that was left by mistake)
* [lldb] 'eval' adjusted to return object of the same type as 'cast'
  method (this improves consistency)
* [gdb/lldb] renamed eval argument to reflect its meaning (it is
  an expression rather than a command)

Resolves tarantool/tarantool#13094
Resolves tarantool/tarantool#13159

Author: elhimov