fix dyno resolution of multi-decls as fields

[arezaii]

Updates the resolution of symbols in the body of a method to properly resolve the type of fields that are part of a multi-decl.

The following reproducer would not resolve properly with --dyno:

class C {
  var a, b : int;
}

proc C.getA() {
  return a;
}

var foo = new C(40, 2);
var x = foo.getA();

because the type of a, although previously identified to be int, would be unknown when evaluating the return type of getA() and make x erroneous.

This was happening because in this specific case we were not normalizing the symbol for the possibility it was an element of a multi-decl or tupledecl or other type of decl that is more like a container for other decls. We were attempting to resolve the type of a without the information about its multi-decl parent.

TESTING:

• [x] new test to make sure the reproducer is fixed
• [x] compiling example with --dyno only produces errors in convert-uast

[reviewed by @DanilaFe - thank you!]

[arezaii]

I added a comment about performance and noted that if we were not changing the defaultsPolicy from USE_DEFAULTS_OTHER_FIELDS to IGNORE_DEFAULTS, the resolveFieldDecl query would likely use the cached result that it created while resolving the class's field declarations rather than recomputing.