feat(executorch): forward ExecuTorch lowering kwargs through save(output_format="executorch")

[Conarnar]

Description

torch_tensorrt.save already forwards partitioners= and backend_config= to the
ExecuTorch lowering. Forward the remaining to_edge_transform_and_lower kwargs the
same way -- pop them in save(), thread them through the three _save_as_executorch
call sites, and pass them to to_edge_transform_and_lower(...):

• constant_methods: bake constant methods (e.g. LLM-runner metadata) into the .pte
• transform_passes: run caller-supplied edge transform passes
• compile_config: override the EdgeCompileConfig. Defaults to
  _check_ir_validity=False (the TRT execute_engine placeholder
  graph fails edge IR validation); a caller-supplied config is
  forwarded verbatim so an explicit _check_ir_validity is honored.
• generate_etrecord: generate + persist an ETRecord as "_etrecord.bin" next
  to the .pte, following ExecuTorch's example convention
  (e.g. examples/cuda/scripts/export.py)

These kwargs only apply to output_format="executorch"; passing any of them with a
different output_format now logs an ignored-kwarg warning, matching partitioners=,
compile_specs= and backend_config=.

Docs: document the lowering options, the compile_config default, the

_etrecord.bin sidecar, and an ETRecord parse/Inspector example in the ExecuTorch saving guide.

Tests

• forward each kwarg through _save_as_executorch, covering an omitted compile_config
  (defaults to _check_ir_validity=False) vs a caller-supplied one (forwarded
  verbatim), and the ETRecord sidecar write.
• forward the kwargs through the public torch_tensorrt.save() across all three
  dispatch branches: an ExportedProgram, a GraphModule with retrace=True, and a
  GraphModule with retrace=False.
• a real lowering with generate_etrecord=True whose sidecar parses back into an
  Inspector-consumable ETRecord via executorch.devtools.

[shoumikhin]

Thanks for adding these save-level controls. This overlaps with the composable ExecuTorch export work in #4440, so I think we should merge #4440 first and then rebase this PR on top of it.

#4440 centralizes engine validation and rewriting, TensorRT-first partitioning, compile-config defaults, multi-method handling, and non-destructive Edge lowering in torch_tensorrt.executorch.export(). After rebasing, _save_as_executorch() should remain a thin one-shot wrapper:

1. call torch_tensorrt.executorch.export(...) with partitioners, compile_specs, transform_passes, compile_config, constant_methods, and generate_etrecord;
2. call edge.to_executorch(config=backend_config);
3. persist the .pte, .ptd, and optional ETRecord sidecar.

That avoids maintaining two TensorRT-to-Edge lowering implementations. backend_config should remain at the final to_executorch() stage because it controls final memory planning rather than Edge lowering.

A few additional items should be addressed during the rebase:

• The new ExecuTorch-only kwargs are popped for every output format, but the warning block still covers only partitioners, compile_specs, and backend_config. The updated docstring says the new options warn when ignored, so please add matching warnings for constant_methods, transform_passes, compile_config, and generate_etrecord.
• The new tests call _save_as_executorch() directly, so they do not exercise option extraction or the three forwarding branches in public torch_tensorrt.save(). Please add coverage through save() for the ExportedProgram route and both GraphModule routes.
• Please avoid bool(kwargs.get("generate_etrecord")). Values such as "false" become True; this should require an actual boolean and forward it unchanged.
• The current ETRecord fake proves only the filename convention. Please add one real lowering test that saves and parses the resulting ETRecord so we know it is Inspector-consumable.
• Since this expands the public save() contract, please also update the ExecuTorch saving guide with the new options, compile-config behavior, sidecar name, and a short parse/Inspector example.

The feature itself is useful; this sequencing should keep save() and the advanced export API on one implementation path.