No-op in case `ELASTIC_APM_ACTIVE` is not set or set to `false`

The [Elastic Serverless Forwarder](https://github.com/elastic/elastic-serverless-forwarder) currently uses the [Python Agent](https://github.com/elastic/apm-agent-python).

The characteristic of the Forwarder is that it's an Application available on the AWS Serverless Application Repository that different users can deploy. Enabling APM tracing and instrumentation is optional: according to the users requirement they may opt-in into it, but by default the feature is not enabled.

We achieve this with our own [`capture_serverless` decorator](https://github.com/elastic/elastic-serverless-forwarder/blob/main/handlers/aws/utils.py#L50-L68): checking for `ELASTIC_APM_ACTIVE` being set as ENV variable, and adding a no-op wrapper in case it's not.
(Additionally we check for `AWS_LAMBDA_FUNCTION_NAME` being set as well, in order to easy local running and integration tests)

I run a test deploying the Forwarder with the AWS Lambda extension layer, and I realised that without setting `ELASTIC_APM_LAMBDA_APM_SERVER` ENV variable the Forwarder lambda execution fails.

Contrary to the Python Agent `capture_serverless` decorator, there is no workaround for this in the AWS Lambda extension.

This prevents the Forwarder to adopt the AWS Lambda extension, that should be the way to go for the future, especially given the [planned support for collecting logs](https://github.com/elastic/apm-aws-lambda/issues/256).

In general, Applications available on the AWS Serverless Application Repository, should be the more flexible they can in providing their own users to optionally enable accessory features like APM, and with the current behaviour there is no way to use AWS Lambda extension without enabling it.

The additional check for `AWS_LAMBDA_FUNCTION_NAME` ENV variable would be optimal, since it will lower the effort required on running the lambda code outside of a real lambda environment, but there might be space for any alternative solution.