fix: Avoid failure if a handler argument is provided to the lambda

[timleslie]

What

This PR adds a workaround for some unexpected behaviour in the combination of LocalStack and clap which can cause environment variable parsing to fail when running Image based lambdas in LocalStack.

Why

When running Image based lambdas in LocalStack, I observed that a command line argument of handler.handler was being provided to the rust binary process. I need to further investigate how/why this is being passed in. I believe it to be a bug, but I haven't confirmed that.

This command line value was in turn parsed by clap as part of our environment parsing. The behaviour of clap was to assign this command line value to the first element of the Env struct, and then ignore any environment variable provided for that element. This caused the wrong value to be provided to the Env struct (although it was considered valid, as my use case expected a String value for this first element). The code would then attempt to parse the HandlerEnv, at which point it would fail, as HandlerEnv.record_concurrency is a usize value, which cannot be parsed from a string.

This PR works around this situation by always passing an empty iterator to Env::try_parse_from(), since we never care about any command line arguments anyway.

[rfk]

Makes sense to me, nice work tracking down what was happening here!