fix #14633: fix error messages for lambdas, identify change points for more complete lambda implementation

[brmataptos]

Description

Catch all errors in move-compiler-v2/tests/checking/typing/lambda.move in Compiler V2,
after splitting and gradually commenting out code as lambda[2-5].move,
to avoid shadowing by other errors. Lay groundwork for support of lambdas in various capacities.

Fixes aptos-labs#14633.

• add checking for function-typed function results in function_checker
• Change internal_error to error in bytecode_generator and module_generator
  to properly show "error" rather than "bug" if lambdas are mistakenly used as values today.
• tag some code to show where changes are needed to support lambda: // TODO(LAMBDA)
• fix unused_params_checker and recursive_struct_checker to tolerate lambda types
• add experiments to control enabling of various aspects of lambda support:
  • LAMBDA_PARAMS, LAMBDA_RESULTS to allow lambdas as general function params or results
  • LAMBDA_FIELDS - support lambdas in struct fields
  • LAMBDA_VALUES - support lambdas in general-purpose values
  • may add LAMBDA_TYPE_PARAMS later
• update lambda-lifting test config to use those flags rather than disabling checks
• add a result_type_loc field to move-model's FunctionData (and model-builder's FunEntry)
  to more precisely locate errors in function result types.
• Fix GlobalEnv::internal_dump_env to use function- and struct-specific type contexts
  so that types are shown with correct type parameter names.
• Check that struct fields are not functions.

How Has This Been Tested?

Running the usual tests.

Key Areas to Review

Note that a few errors are caught quite late, in bytecode-generator,
and the order in which we catch errors may be a bit surprising to
users (errors in exp_builder come first, then errors caught by
function_checker, then (much later) bytecode_generator.).
Actually supporting particular subsets of the "experiments" mentioned
above would be difficult, but it seems useful to have the labels to
help understand just what features are supported by the implementation
as we go.

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

[brmataptos]

• fix #14633: fix error messages for lambdas, identify change points for more complete lambda implementation #1 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @brmataptos and the rest of your teammates on Graphite