Add hlfir.associate and hlfir.end_associate codegen.
To properly allow reusing the bufferized expression storage for the
newly created variable, bufferization of hlfir.expr has to be updated
so that hlfir.expr are translated to a variable and a boolean to
indicate if the variable storage needs to be freed after the expression
was used. That way the responsibility to free the bufferized expression
can be passed to the variable user, and applied in the
hlfir.end_associate.
Right now, not of the bufferized expression are heap allocated, so
generating the conditional freemem in hlfir.end_associate is left as
a TODO for when it can be tested.
It looks like there is an implicit assumption that there are no mlir::TupleType operands in the operations that are transformed by this pass before this pass launches OR if such operands are present and they match the tuple<variable address, cleanupFlag> pattern, then they indeed represent the bufferization package. Am I reading it right? It seems somewhat subtle to me, and I would rather use a distinct FIR type to represent the package so that values of this type have a well-defined meaning. I guess it should be okay as-is if we do not expect mlir::TupleType operands ever appear elsewhere.