fix(lambda): fix lambda instr to work with a '.' in the handler module path

[trentm]

Before this if the _HANDLER string had a '.' in the module path (the
part before the 'moduleName.functionExport'), then the parsing of
that handler string would silently produce bogus 'lambdaHandlerInfo'
that would result in a RITM path that would never actually get loaded,
hence no Lambda instrumentation.

Fixes: #4293

[trentm]

I've verified manually that this works in a real Lambda with a leading './' on the handler path.
I see this log output line:

2024-11-01T22:57:51.242000+00:00 2024/11/01/[$LATEST]395d9c62d54d40c08e373171c8fad153 {"log.level":"debug","@timestamp":"2024-11-01T22:57:51.238Z","log.logger":"elastic-apm-node","ecs.version":"8.10.0","message":"instrumenting /var/task/src/functions/hi/handler.js@$LATEST module (enabled=true, isImportMod=false)"}

and instrumentation works.

testing the added log.warn

I then broke the implementation again, but kept the log.warn's. I published a new layer and ran my test Lambda with that.
Instrumentation, again, isn't working (as expected) and I see this log.warn:

2024-11-01T23:01:13.136000+00:00 2024/11/01/[$LATEST]279be659b3e14d49aa948e43ecbfb74e {"log.level":"warn","@timestamp":"2024-11-01T23:01:13.128Z","log.logger":"elastic-apm-node","ecs.version":"8.10.0","fullHandlerString":"./src/functions/hi/handler.main","moduleRoot":"./src/functions/hi/","module":"","message":"could not find Lambda handler module file (ESM not yet supported)"}

This hopefully, will give us a clue if we hit an issue again. E.g. we don't support .mjs handler modules yet, so we expect to see a warning.