Add return value to `CaptureFeedback`

[bitsandfoxes]

Description

Problem Statement

CaptureFeedback is a user facing (not just our users, but actually our users' user) method, where there is no way to validate successful capture right now.

Context

sentry-dotnet/src/Sentry/SentrySdk.cs

Line 536 in dc2b326

public static void CaptureFeedback(SentryFeedback feedback, Action<Scope> configureScope, SentryHint? hint = null)

CaptureFeedback returns void right now. There are multiple conditions why the SDK might fail to send the feedback

sentry-dotnet/src/Sentry/Internal/Hub.cs

Lines 559 to 564 in dc2b326

	CaptureFeedback(feedback, clonedScope, hint);
	}
	catch (Exception e)
	{
	_options.LogError(e, "Failure to capture feedback");
	}

sentry-dotnet/src/Sentry/SentryClient.cs

Lines 87 to 91 in dc2b326

	if (string.IsNullOrEmpty(feedback.Message))
	{
	_options.LogWarning("Feedback dropped due to empty message.");
	return;
	}

The feedback could be dropped and without reading the logs, users will never know that it happened.
Capturing the feedback ends with a call to CaptureEnvelope which does return a bool but that gets swallowed right now.

sentry-dotnet/src/Sentry/SentryClient.cs

Lines 114 to 116 in dc2b326

	var attachments = hint.Attachments.ToList();
	var envelope = Envelope.FromFeedback(evt, _options.DiagnosticLogger, attachments, scope.SessionUpdate);
	CaptureEnvelope(envelope);

Proposal

Similar to how it is done in CaptureEvent calling CaptureFeedback should return the event ID.

sentry-dotnet/src/Sentry/SentryClient.cs

Lines 73 to 81 in dc2b326

	try
	{
	return DoSendEvent(@event, hint, scope);
	}
	catch (Exception e)
	{
	_options.LogError(e, "An error occurred when capturing the event {0}.", @event.EventId);
	return SentryId.Empty;
	}

This would allow

1. Users to validate whether the event/feedback was actually sent
2. Users to display the captured event ID to their users

[jamescrosswell]

Thanks @bitsandfoxes - sounds sensible. Technically this would be a binary breaking change... but unless people are calling the method via reflection (extremely unlikely) I don't think it would break anyone's code when they recompiled if we added a return value, so I don't see any issues adding it.

@Flash0ver ?