* [wasm] Mark result as Error if it has 'exceptionDetails' field

* [wasm] Don't swallow errors from methods that enumerate properties

.. like for getting locals. Instead, surface the original errors which
have details of the actual failure, to the point before we send a
response.

This helps debugging a lot, so instead of `Unable to evaluate dotnet:scope:1`,
we get more detailed errors.

* [wasm] Throw an exception when a debugger agent command fails

We are checking `HasError` property on the binary reader in very few
places. Other places just try to use the reader which then fails with
errors in reading, or base64 conversion etc, and we don't get any info
about what command failed.

Instead, throw an exception on error by default. But the existing
locations that do check `HasError`, don't throw for them.

* [wasm] Fix evaluating expression calling a non-existant method

Issue: dotnet#65744

The test doesn't fail because it is expecting an error, and it gets
that.

But the log shows an assertion:

`console.error: * Assertion at /workspaces/runtime/src/mono/mono/metadata/class-accessors.c:71, condition `<disabled>' not met`

1. This is because the debugger-agent does not check that the `klass`
argument is NULL, which is fixed by adding that check.

2. But the reason why this got called with `klass==NULL`, is because
`MemberReferenceResolver.Resolve` tries first to find the non-existant
method on the type itself. Then it tries to find the method on
`System.Linq.Enumerable`, but fails to find a typeid for that.
  - but continues to send a command to get the methods on that
  `linqTypeId==0`.

* [wasm] Add some missing exception logging in the proxy

* cleaup

* [wasm] GetMethodIdByName: throw on invalid type ids

* [wasm] Improve error handling in expression evaluation

* Cleanup

* Disable failing test - dotnet#65881

* Add missed files

* Address @ilonatommy's feedback