feat(lib): add native NodejsFunction with Rolldown bundling

[garysassano]

Related issue

Closes #401

Description

Adds native NodejsFunction construct with Rolldown bundling, deterministic ZIP assets, and automatic IAM and logging setup:

import { NodejsFunction } from "@cdktn/aws-lambda-nodejs";

new NodejsFunction(stack, "hello", {
  entry: "src/hello.ts",
});

The unpublished TypeScript/JavaScript packages expose native Rolldown controls, validate build inputs and ZIP limits, and include package guides and a runnable example. Native addons require prepared files or layers.

Validation: 49 package tests, all 542 core tests, builds, lint, formatting, dependency and packed-consumer checks pass. AWS deployment, invocation, code updates and cleanup passed; all 12 resources were confirmed absent.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[so0k]

I think this PR has interesting components that we may want to split and rebase:

1. Bundling
2. AWS Specific L2 Construct

These depend on an ongoing effort for defining a cross-cloud Asset (and bundling) mechanism as per #380 (also referenced in the issue driving this PR).

Can we first align on how to slice and land these?

Additionally - I think we aim to keep open-constructs/cdk-terrain provider independent, the github.com/cdktn-io org is where we have provider specific libraries and where I think L2 constructs as well as cloud specific capabilities like the NodeJsFunction (backed by terraform-provider-aws) should live.

Currently you may use https://github.com/TerraConstructs/base/tree/main/src/aws/compute/function-nodejs which is already an exact Port of AWSCDK L2 + Asset Pipeline (as well as decoupled bundling). So perhaps the changes proposed here could improve that existing AWS L2 specific construct?

Another consideration is the ongoing work to integrate with AWSCDK specifically through the AWSCC+cfncompat provider which is the ideal way forward.

• https://github.com/cdktn-io/terraform-provider-cfncompat/blob/main/RFCs/GROUND_TRUTH.md
• https://github.com/cdktn-io/cdktn-awscc/blob/main/generated/aws-lambda/function.ts#L214

in conclusion:

1. Bundling should be aligned with the ongoing effort around the definition of clear interfaces that belong in the core package(s) to support an Asset Pipeline (and which parts are synth-time; in the cdktn CLI or APPLY time leveraging capabilites like exec-local or provider resources|actions|functions
2. AWS Specific could go be via a cdktn-io package?

Let's align and discuss via cdk.dev slack and perhaps on the next CDKTN Sync-up call?