* [wasm][debugger] Send var names also, to `mono_wasm_get_variables`

- this will be useful in upcoming commits, which will need to use the
names for local pointer vars

* [wasm][debugger] Add support for deref'ing pointers

* [wasm][debugger] Dereference the pointer in js, instead of debugger.c

Based on suggestion from @vargaz

* [wasm][debugger][tests] Fix setting async methods when setting

.. breakpoint by method name. Async methods themselves don't have the
debug information. Instead, that can be found on the generated async
implementation type/method. Here, we just look for a type name
starting with `{original_type_name}/<{async_method_name}>`, and use the
method `MoveNext` from that.

* [wasm][debugger][tests] Update to set bp by method name+lineoffset

* Address review comments from Katelyn Gadd (@kg)

* Add test to check deref'ing invalid pointers

- We should really be handling invalid object ids, and report errors for
those, where appropriate. This will be done in a future PR
- For this PR, I'm adding tests that just check that invalid objects, or
trying to deref regular objects, doesn't blow up

* Remove old unused test code

* [wasm][debugger] Use JsonConvert instead of manually building the json string

- addresses review comment from @lewing

test: `DebuggerTests.ValueTypesTest:MethodUpdatingValueTypeMembers`

- In some places we weren't checking for the `description` property
- and this hid a bug where sometimes that property wasn't added (eg. for
numbers)
- Instead, we were working around that by "fixing it up" later

- Now, we use the same checks for `Check{Number,String,*}` API, and the
`CheckValue/CheckProps` API used with `TNumber` etc.

- So, this commit:
	- fixes the checks, and the tests
	- and fixes the bug

- these are of the form `dotnet:${scheme}:{id-args-object}`
- Examples:
	- `dotnet:valuetype:{ containerId: 4 }`
	- `dotnet:valuetype:{ num: 2 }` - the `num` field is
	autogenerated if no id-args are provided. This gets used when
	valuetypes are expanded.

- `this._id_table [id-string]` has associated property objects for every
`id`
	- This might contain, for example, `klass` pointer, and base64
	representation of a valuetype

.. to use a single function to get details of the full array, and
individual elements.

- Allow `_new_id` to update properties for existing objectIds
- Extract valuetype id assigment code to a separate function

- add some new getters to the test classes
- this will become useful in subsequent commits that add support for
invoking getters on valuetypes

- this also becomes useful in subsequent commits which enable invoking
getters on valuetypes

- keep a copy of the value bytes, and the klass pointer
- this allows being able to invoke getters on such a valuetype, at a
later point
- This allows getters like `DateTime.Date`, which has the type
`DateTime`

.. and replace `var` with `let`, or `const`, where appropriate.

.. especially the ones that return data in `MONO.var_info`.

To use:

1. `this._register_c_var_fn ('mono_wasm_get_object_properties', 'bool', [ 'number', 'bool' ]);`
2. Now, this function can be called as `this.mono_wasm_get_object_properties_info (.. )`
    - returns `res` which has the contents of `MONO.var_info`, after running
    `_fixup_name_value_objects` on it.

- functions like those for getting object/vt properties, can fail, for
example, if the objectId is invalid.
- We now return that bool result, and that gets surfaced to the caller

- This will also help to differentiate the case where the result of such
a function was a failure vs just an empty result

- These tests don't actually depend on the error message, and we don't
have another to way to differentiate why a command might have failed
with an exception. So, right now, they will pass as long as the commands
fail as expected.

- Future TODO: return `error`, instead of exception details for issues
in `mono.js`, like incorrect input, invalid id etc, and update these
tests accordingly.