Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- Add Hint support ([#2351](https://github.com/getsentry/sentry-dotnet/pull/2351))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against af95623

With respect to BeforeBreadcrumb support, I see the only place BeforeBreadcrumb gets used is in Scope.AddBreadcrumb.

SentryEvent, Transaction and TransactionTracer implement IHasBreadcrumbs, which also has an AddBreadcrumb method... but none of those call BeforeBreadcrumb before adding a breadcrumb. I assume that's all by design but what is the rationale for being able to filter breadcrumbs before they get added to the Scope vs when they get added to the other IEventLike implementations?

The Scope class has a Transaction property... so presumably someone could call Scope.Transaction.AddBreadcrumb which would result in a breadcrumb being sent with the Transaction associated with the Scope, but no opportunity to intercept this via BeforeBreadcrumb? I'm guessing there's more going on here... do the Breadcrumbs from Scope.Transaction and SentryEvent get moved over to the Scope before anything gets sent to Sentry?

I fixed the iOS build issue. The Cocoa SDK doesn't have hints yet, and as you pointed out in comments, the Android SDK doesn't really let us propagate hints. But this is fine for now. We can address later with some coordination with the other teams if we think it will add value.

We need to do the same with BeforeSendTransaction that we did with BeforeSend and BeforeBreadcrumb. That should be fairly straightforward.

But also we need to supply hints for event and transaction processors (not exception processors). I was thinking that we should use default interface methods for this, but I think a cleaner approach is to implement abstract classes instead. Specifically:

public abstract class SentryEventProcessor : ISentryEventProcessor
{
    SentryEvent ISentryEventProcessor.Process(SentryEvent @event)
    {
        throw new NotImplementedException();
    }

    public abstract SentryEvent? Process(SentryEvent @event, Hint hint);
}

public abstract class SentryTransactionProcessor : ISentryTransactionProcessor
{
    Transaction ISentryTransactionProcessor.Process(Transaction transaction)
    {
        throw new NotImplementedException();
    }

    public abstract Transaction? Process(Transaction transaction, Hint hint);
}

So if one wants hints in processors, they implement the abstract class. We can remove the current interfaces in the next major release (v4.0.0).

Where we have usages of ISentryTransactionProcessor, we can check if it is an instance of SentryTransactionProcessor and call it with the hint.

The alternative would be to provide a completely separate ISentryTransactionProcessorWithHint interface, and all methods and fields to track them. I think the other approach is easier.

I think I've taken this as far as I can. Let me know when you get a chance to review... and @mattjohnsonpint would be great to get your wisdom on the CI Build error since the most recent merge from main.