HA_xOPTION_SYSVAR table-option resolver lacks GET_DOUBLE (and signed integer) cases: DBUG_ASSERT(0) in debug builds, unresolved option type / wrong struct size in release builds

`HA_TOPTION_SYSVAR()`/`HA_FOPTION_SYSVAR()`/`HA_IOPTION_SYSVAR()` let a storage engine
expose a plugin system variable as a `CREATE TABLE` option. At engine load,
`ha_initialize_handlerton()` calls `resolve_sysvar_table_options()`, which calls
`plugin_opt_set_limits()` for each option and then switches on the resulting
`var_type`.

The switch in `sql/create_options.cc:408-459` handles `GET_ULL`, `GET_ULONG`,
`GET_UINT`, `GET_STR`, `GET_STR_ALLOC`, `GET_BOOL` and `GET_ENUM` only. For a plugin
sysvar declared as `MYSQL_SYSVAR_DOUBLE`/`MYSQL_THDVAR_DOUBLE`, `plugin_opt_set_limits()`
yields `GET_DOUBLE` (`sql/sql_plugin.cc:3834-3836`, `:3856-3858`); signed integer sysvars
yield `GET_INT`/`GET_LONG`/`GET_LL`. Those values hit the `default: DBUG_ASSERT(0)`
branch at `sql/create_options.cc:453-455` and the function still returns success, leaving
`opt->type == HA_OPTION_TYPE_SYSVAR`.

In a debug build the assertion aborts during engine initialization / plugin load. In a
release build the assert is compiled out: the unresolved type survives, and later
`create_table_option_struct_size()` indexes the four-entry `ha_option_type_sizeof[]`
table (`sql/create_options.cc:247-248`) at index 4 (`:393-394`), producing an
out-of-bounds read / wrong structure size; `set_one_value()`'s
`case HA_OPTION_TYPE_SYSVAR: break` (`:138-140`) then reaches
`DBUG_ASSERT(0)` + `my_error(ER_UNKNOWN_ERROR)` (`:242-244`), so `CREATE TABLE` on such
an engine fails at best.

1. 1. Expected result

`resolve_sysvar_table_options()` should handle `GET_DOUBLE` and the signed integer types
(or reject the option at registration with a clear error), so a plugin that declares a
`double` sysvar in `HA_TOPTION_SYSVAR` either works or fails predictably — never an
assertion, out-of-bounds table index, or silently wrong option-struct size.