Total AST decoration, closure serialization from FunctionlessAST and higher-order function capabilities

[sam-goodwin]

Now that our AST is 1:1 with TS, we can replace the async closure serializer that uses the debugger API with one that simply serializes the FunctionlessAST -> TypeScript and runs the result through es-build to produce a final bundle.

• Remove ambiguity from TemplateExpr and TaggedTemplateExpr #373
• Refactor Lambda/Function closure serializer field removal #239
• remove the work that the compiler does to flatten references and move that logic into interpreters feat: remove logic in compile.ts to flatten references to expressions #376
• remove PromiseExpr and PromiseArrayExpr
• missing AST information for function modifiers feat: add isAsync and isAsterisk to function expressions and isOptional to ElementAccessExpr #382
• missing AST information - const, let or var in VariableDeclList feat: add isAwait to ForOfStmt and isRest to ParameterDecl, fix TemplateExpr #389
• missing AST information for for await (const i of) feat: add isAwait to ForOfStmt and isRest to ParameterDecl, fix TemplateExpr #389
• missing AST information - while loops, for loops without BlockStmt, e.g. while (cond) a = b
• missing AST information - the variable declarations in for-loops must use a VariableDeclList
• unnecessary AST information - Argument node type has no purpose
• ensure that swc-jest + our transformer can be run during tests
• swap out the ts-transformer for swc and apply it as a require hook
• update IAM policy inference to support exploring function references, recursion and higher-order functions, etc. Lambda: detect transitive dependencies from higher-order functions #310
• replace pulumi's closure serializer with one that translates FunctionlessAST into javascript instead of relying on debugger APIs and parsing function.toString() like how pulumi does it

[sam-goodwin]

I'm running into a fundamental question: should integration discovery be bottom-up or top-down? We currently do it bottom-up by calling functions such as isIntegrationCallPattern on a node and expecting that to resolve to a single integration via ReferenceExpr. Now that the transformer logic is being removed, we have to resolve that expr to an Integration by walking backwards (as we've discussed). This is a bottom up algorithm that is usually ideal for type-checking algorithms.

I'm not sure this is ideal for detecting all of the Integrations which is closer to an evaluation algorithm (explore all pathways of the code) - a top-down walker.

I'll start implementation with a bottom-up algorithm to replace the adapt the isIntegrationCallExpr algorithm to do the work that our transformer was doing, but I think we will have to dig deeper into this decision as we expand the capability of IAM Policy Inference of the Lambda serializer..