Avoid undefined behavior in expression dumping

Avoid undefined behavior in expression dumping

-fsanitize=undefined pointed out undefined behavior in
dump_raw_expression like:

    runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'

dump_raw_expression will try to print the opcode for each element of
the expression, even when it is not valid.  To allow this, but have it
avoid undefined behavior, this patch sets the underlying type of enum
exp_opcode, and arranges for op_name to handle invalid opcodes more
nicely.

Before this patch, debug-expr.exp shows:

Dump of expression @ 0x60f000007750, before conversion to prefix form:
	Language c, 8 elements, 16 bytes each.
	Index                Opcode         Hex Value  String Value
	    0               OP_TYPE  89  Y...............
   <unknown 3851920>  107820862850704  ..:..b..........
	    2               OP_TYPE  89  Y...............
	    3          OP_VAR_VALUE  40  (...............
	    4     <unknown 2807568>  107820861806352  ..*..b..........
	    5     <unknown 2806368>  107820861805152  `.*..b..........
	    6          OP_VAR_VALUE  40  (...............
	    7      UNOP_MEMVAL_TYPE  57  9...............

Afterward, the output is:

Dump of expression @ 0x4820f90, before conversion to prefix form:
	Language c, 8 elements, 16 bytes each.
	Index                Opcode         Hex Value  String Value
	    0               OP_TYPE  89  Y...............
	    1   unknown opcode: 176  75444400  .0..............
	    2               OP_TYPE  89  Y...............
	    3          OP_VAR_VALUE  40  (...............
	    4               OP_BOOL  74616912  P.r.............
	    5   unknown opcode: 128  74615680  ..r.............
	    6          OP_VAR_VALUE  40  (...............
	    7      UNOP_MEMVAL_TYPE  57  9...............

gdb/ChangeLog
2018-10-03  Tom Tromey  <tom@tromey.com>

	* expression.h (enum exp_opcode): Use uint8_t as base type.
	* expprint.c (op_name): Handle invalid opcodes.