Fix named argument unification

[TimWhiting]

Previously the unification didn't match the named argument eta-expansion / type matching.

This could cause surprising behavior where ?@copy:(a, x:int, y:int) -> a unified with ?@copy: (a, dx: int, dy: int) -> a, resulting in updates to the wrong fields of a struct.

Names have become more useful in type inference recently due to our update to allowed named arguments anywhere in the call site, and handled providing the correct optional parameters in eta expansion for implicits.

This PR fixes the unification behavior to match the rest of type checking and eta-expansion. In other words, names matter, and are part of the type when given as part of the type.

Unfortunately, the compiler / standard library and many tests add names in the type as internal function documentation and not intended for outside contracts. So this PR needs text fixes.

However, I think this probably needs discussion - and test fixes, so I'm leaving as draft, to allow us more time to discuss.

It might be useful to add a variant of function type annotation where arguments with a prefix of _ are "hidden" positional arguments with documented names to have parameter names not become part of types - especially for parameters typically given positionally and or to enforce that they should not be given as named. In some languages like Swift they have "argument labels" in addition to "parameter names", the label is how it is referred to inside the function, whereas the name is what can be given outside for named arguments.

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions#Function-Argument-Labels-and-Parameter-Names