SendGrid API response handling

[nicbavetta]

This pull request contains modifications to enable extensibility through SendGrid API response handling. Previously, if a response from the SendGrid API indicated a result other than success (defined, by this extension, as status code >= 300), an exception would be thrown when the SendGridMessageAsyncCollector was flushed. This implementation made it difficult to react to responses in meaningful ways.

Additions

1. ISendGridResponseHandler - This interface can be implemented to allow business logic to be executed against responses from the SendGrid API.

2. DefaultSendGridResponseHandler - The default implementation for the interface above. If consumers of this extension do not implement and register the ISendGridResponseHandler with DI, then the DefaultSendGridResponseHandler will be used. This handler implements the logic that was previously implemented when SendGrid responses were received with status codes >= 300. The status code evaluation has been changed to >= 400, per SendGrid documentation.

Modifications

1. The ISendGridClient and SendGridClient have been removed in favor of leveraging the client interface/implementation provided by the SendGrid SDK.
2. Namespaces in this project have been made to be consistent.
3. As mentioned previously, SendGrid response status code evaluation has been changed to >= 400, per SendGrid documentation.
4. Some null-checks have been added in modified constructors to better convey explicit requirements.

[net-foundation-cla]

All CLA requirements met.

[nicbavetta]

@mathewc or @brettsam - Any chance this PR can get evaluated? The unsuccessful checks from the AppVeyor build are not related to my work.

[fabiocav]

@nicbavetta thank you for the contribution!

Looks like the scope of the changes was inflated by some other refactoring.
Could you please remove the refactoring that isn't directly related to the work? Any refactoring work can be submitted as a separate PR.

This change also introduces a lot of type name/namespace changes, which would need to be removed as those are breaking within a major version.

Thanks!

[nicbavetta]

@nicbavetta thank you for the contribution!

Looks like the scope of the changes was inflated by some other refactoring.
Could you please remove the refactoring that isn't directly related to the work? Any refactoring work can be submitted as a separate PR.

This change also introduces a lot of type name/namespace changes, which would need to be removed as those are breaking within a major version.

Thanks!

See #709 for the new PR. @fabiocav