codegen: better support for openArray

[zerbina]

Summary

Fix multiple issues related to the openArray type across all three
code generators. The intention is to make using the type stable
enough for the inlining logic in transf to use it as the type for
locals and object fields.

The unstable sink openArray feature stops working with the changes
here: its viewed elements are no longer destroyed when exiting the
routine accepting a sink openArray as a parameter.

Details

A big part of the changes is to treat var|lent openArray types the
same an unqualified openArray during the mid- and back-end phase of
compilation. In the future, the types should be lowered into openArray
prior to reaching the code generators.

The following list of changes is ordered by compilation phase, with the
earlier steps coming first.

Operator Lifting

openArray types are treated as primitive types, with a normal
assignment being used for copying and sinking, and destruction being a
no-op. This is necessary in order for copying the view to work.

This breaks sink openArray, which relied on a non-trivial destroy hook
that destroyed all element being generated for openArray.

MIR generation

Semantic analysis insert snkHiddenAddr and nkHiddenDeref nodes for
var openArrays. This is both unnecessary and confuses the code
generators, as no indirection is used and thus no taking the address /
dereferencing is needed.

While this ultimately needs to be fixed in sem, it is for now worked
around in mirgen: if the operand to nkHiddenAddr or nkHiddenDeref
is an openArray, the operator is ignored.

To make working with view types easier in the compiler's mid- and back-
end part, the classifyBackendView procedure is introduced, which for
the provided type computes whether it's a single-location view
(var|lent with non-openArray element), view of a sequence
(openArray), or no view.

Code generation

cgen

• introduce the ctNimOpenArray enum field
• map var|lent openArray to the same C type as an unqualified
  openArray
• base genAssignment and constructLoc on the C type, instead of
  the NimSkull type, fixing assignment and initialization of
  var|lent openArrays
• fix the C type-name caching logic to not cache var|lent openArray
  types

jsgen

• implement default initialization and type info creation for
  openArray. This is required for openArrays to be part of compound
  types (arrays, tuples, objects)
• include tyOpenArray in the list of "no copy" types
• prevent a call to nimCopy during initialization when the destination
  is an openArray

vmgen

Refactor:

• rename isVarLent to isLocView and use classifyBackendView
• use classifyBackendView for isDirectView

Change:

• isLocView only returns 'true' for single-location views
• consider all direct views in isDirectView (openArray was missing)
• consider all direct views (not only single-location ones) for
  assignments (genSymAsgn) and initialization (genVarStmt)

[saem]

Memorializing thoughts at this point in time with respect to openArray (no change is required for this PR, just leaving a trail):

after coming back to openArray for so long and rereading the previous discussion. The only way sink openArray makes sense is if we treat openArray as a typeclass meaning any array/sequence/etc, and all parameter occurences make it generic and bind once as typeclasses do. While openArray[T] etc... are generic views, but that seems weird.

[saem]

We'll need this sort of categorization for views (and locations), starting it here is based on current needs seems sensible.

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• unblocks transf: fix inline iterator invocation semantics #745
• the commit messages provide additional information
• I'm not sure about the name classifyBackendView
• given what has been said in disallow sink openArray[T] types #544, I think sink openArray breaking is okay