fix: Allow SendGridMessage serialization to optionally bypass defaults

[duncanchung]

Fixes #1063

Fixes

Restores serialization of the SendGridMessage to that prior to #938 , but also adds the ability to bypass custom serialization settings (see #937 )

Will add discussion in comments.

Checklist

• I acknowledge that all my contributions will be made under the project's license
• I have made a material change to the repo (functionality, testing, spelling, grammar)
• I have read the Contribution Guidelines and my PR follows them
• I have titled the PR appropriately
• I have updated my branch with the main branch
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation about the functionality in the appropriate .md file
• I have added inline documentation to the code I modified

[duncanchung]

It seems my pull request #938 was actually backwards incompatible.

The core of the issue is the CamelCasePropertyNamesContractResolver (which I would say is commonly used - though I don't know why there are only 2 reported issues on #938 ).

When used, it camel-cases dictionary keys (so you can never control the casing on e.g. email headers) and affects property names (e.g. template data).

Now, the only way to get control back on the email headers is to effectively reset the serialization (which was #938 ) but then e.g. all your template data won't match. (e.g. your template expects firstName and you are now passing FirstName).

This pull request is just a backwards compatible way to do #938 , defaulting to existing behavior and predictable .Net conventions (ie. serialization follows the application's JsonConvert.DefaultSettings [if modified]), with an explicit override on the Serialize method to reset back to NewtonSoftJson defaults. This way, you opt in to the reset of the serialization, and therefore opt in to resetting all templates, etc. to follow untainted NewtonSoftJson defaults.

[thinkingserious]

Thank you for the quick turn around on the fix!