Fixed an issue where delimited string and primitive values in payload were not parsed properly by Lambda Test Tool.

[ashishdhingra]

Issue #, if available: #1135

Description of changes:
Fixed an issue where delimited JSON string payload was not parsed properly by Lambda Test Tool. This PR ports the string handling from .NET Lambda CLI tooling. .NET CLI Extensions tooling per logic here delimits the raw string payload with " if it doesn't start with {. JSON strings are enclosed in double quotes:

if(!invokeRequest.Payload.StartsWith("{"))
{
    invokeRequest.Payload = "\"" + invokeRequest.Payload + "\"";
}

Per testing with dotnet lambda invoke-function:

• For dotnet lambda-test-tool-6.0 --no-ui --payload ""hello"", payload should be parsed as hello.
• For dotnet lambda-test-tool-6.0 --no-ui --payload '"hello"', payload should be parsed as 'hello'.

EDIT: Per discussion with @normj, the implementation in .NET Extensions for CLI would not handle primitive types and needs to be fixed (refer #1197). I have implemented changes as suggested in this PR. Would work on .NET Extensions CLI tooling as part of issue #1197.

---

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

[normj]

I'm worried the logic we added in Amazon.Lambda.Tools isn't great logic to duplicate. The problem with the Amazon.Lambda.Tools logic is what if you want to send a bool or an int. This logic automatically converts true to "true" or 100 to "100".

I wonder instead if we should attempt to parse the JSON using with System.Text.Json. If that parses with no problems then send as is. If it doesn't parse add surrounding quotes if it doesn't already start with quotes then use that value. We could retrofit Amazon.Lambda.Tools with the same logic. I wouldn't view that as a breaking change there and we would fix some scenarios that aren't working correct in Amazon.Lambda.Tools.

[ashishdhingra]

Implemented fix. Please review.