feat: Support all formats of function name in invoke

[bchampp]

Fixes #8289

Which issue(s) does this change fix?

#8289

Why is this change necessary?

The lambda invoke API supports multiple different formats for the function name parameter. However, SAM only supports matching the function name directly as it exists in the provided SAM template.

How does it address the issue?

This change updates SAM so that we support more flexible function name arguments. Now, we normalize the provided function name to be just the function name by extracting it from the full or partial ARN, and/or stripping the version provided.

Now, when invoking a function locally, we first normalize the provided function name field to extract just the function name.

Testing:
I have a SAM template which has a function "HelloWorld". I tested by invoking different variations that are supported of the function name:

# works as it did before
samdev local invoke HelloWorld

# alias, invokes HelloWorld function
samdev local invoke HelloWorld:alias 

# full function arn, invokes HelloWorld function
samdev local invoke arn:aws:lambda:us-east-1:123456789012:function:HelloWorld

# partial function arn, invokes HelloWorld function
samdev local invoke 123456789012:function:HelloWorld

I also updated the error handling around invalid function names to match what the lambda service does:

samdev local invoke :HelloWorld
                                                                                                                                                                                                                                                                 
Error: 1 validation error detected: Value ':HelloWorld' at 'functionName' failed to satisfy constraint: Member must satisfy regular expression pattern: ^(arn:[^:]+:lambda:[^:]*:\d{12}:function:|\d{12}:function:)?[a-zA-Z0-9-_\.]+(:[\w$-]+)?$

What side effects does this change have?

None.

Mandatory Checklist

PRs will only be reviewed after checklist is complete

• [N/A] Add input/output type hints to new functions/methods
• [N/A] Write design document if needed (Do I need to write a design document?)
• Write/update unit tests
• [N/A] Write/update integration tests
• [N/A] Write/update functional tests if needed
• make pr passes
• [N/A] make update-reproducible-reqs if dependencies were changed
• Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.