Fix Log::Builder append BroadcastBackend to itself

[straight-shoota]

Resolves #13404

The first commit fixes the immediate bug of adding a broadcast backend to itself.

The second one refactors the builder to avoid mutating a user-provided BroadcastBackend entirely
This is implemented via a flag to indicate whether a Log's backend is user-provided or implicitly created for this log instance.

[bcardiff]

I'm surprised that the user_provided_broadcast_backend leaves in the Log class instead of being a state tracked inside the Log::Builder directly or in the BroadcastBackend itself. Having a boolean or a @auto_created : Set(BroadcastBackend) in the Log::Builder seems enough without increasing the memory size. Am I missing something?

The private def remove_backend needs to be updated also since it can mutate the broadcast backend also. It is used as part of the spec helper methods for capturing logs IIRC.

[straight-shoota]

Yeah, I wasn't sure where exactly to put that. BroadcastBackend seemed like a bad place because it really shouldn't care about how it's used. Builder would be a natural place because it owns the backend. But it's not as straightforward because its responsibility spans multiple Log instances.
I suppose registering the instances would be another viable option. Lookup costs are a bit higher, but that shouldn't matter much because the builder usually runs sparsely.

[straight-shoota]

I found a cleaner solution by checking @bindings whether the given broadcast backend was explicitly bound to. If not, it was auto-generated.

remove_backend does not necessarily require any special handling because unbind already verifies that the backend is registered in @bindings. So you cannot accidentally unbind a backend from a user-provided broadcast backend.