[wasm][debugger] Support indexing of valuetype scheme

[ilonatommy]

Follow-up for #92630.

Changes in tests:

• We will be using similar mechanisms for struct like we do for class - refactored TestEvaluate class into CommonCollections, ClassWithIndexers and StructWithIndexers to avoid code duplication. f was an ambiguous name, now we have c for class and s for struct.
• We need a test case with both: indexers and inline arrays on the same object, so inline arrays from array tests got exposed and added to class/struct indexers.
• Added a check for invoking methods on inline arrays - works fine.
• Multidimensional indexing of value types.

Changes in logic:

• Added checking LiteralExpressionSyntax arguments for compatibility - this revealed a small overlooking in CheckParameterCompatibility switch case - when the method expects ElementType.Boolean we cannot send string or char type as a param, it's not compatible.
• Unified indexing resolving mechanism for objects and value types, now both use get_Items method (InvokeGetItemOnJObject).
• Added receiving inline arrays on value types in the runtime, we used to read their sizes but then ignore reading the contents.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Follow-up for #92630. After merging this PR we will be able to fix multidimensional indexing of valuetypes.

Author:	ilonatommy
Assignees:	ilonatommy
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[radical]

What is needed, or missing to do this?

[radical]

Your idea here is the better approach.

[ilonatommy]

Reason why it might be not possible:

1. If the parameter is required (as opposed to default) then we don't have information about its type. Even though we know what types were passed to the method, we cannot tell if this method will work well with them till we ask the runtime to CMD_VM_INVOKE_METHOD and it will throw / return a result.
2. Sometimes we even are not sure what type was passed to the method, see [wasm][debugger] Evaluate methods with short arguments #93057.
   It would be good to try if something changed but please, not in this PR. I will see if I can make it in a separate one.
   Edit:
   Trying to create the new PR I found a good example for situation 1).

void foo(Class1 c);
void foo(Class2 c);

When we ask for GetMethodIdsByName for "foo" we will get both methods' IDs. We can check both method parameter types by refection but the information we will get is ElementType.Class which does not tell us enough.

[radical]

note: be careful with changing existing test code, as it can be easy to break tests even when we think we changed the line numbers correctly, especially if they end up affecting line numbers used for breakpoints for instance. Such a change might not break a test immediately, but it might now be stopping on the incorrect line opening a potential for the test not doing the intended checks.