honeycomb: incorporate into observation package and improve `internal/honey` API

Created by: Strum355

Why

1. Previously, internal/honey was a very raw and low-level wrapping around libhoney-go. Handling of honeycomb being not enabled was not transparent, with nil checks being required before adding extra fields to an event that may not have been created.
2. To continue Erics dream of internal/observation being the central package for all things observability, and to avoid duplicated effort of using internal/observation and honeycomb at the application logic level, honeycomb had to be transparently incorporated into it.

How This PR reworks internal/honey and internal/observation in a multitude of ways:

1. Creates an interface around a *libhoney.Event with extras, implemented as:
   • A wrapper around a basic *libhoney.Event
   • A noop event which should reduce if event != nil usage
2. Incorporates honeycomb on a opt-in basis to internal/observation.Context, adding the log fields as data along with some extra meta like op name, num goroutines, mem usage, version etc
3. A Dataset type as a convenience/typed approach to specifying the dataset name, example https://github.com/sourcegraph/sourcegraph/pull/27964/files#diff-e53a07f3674b9472217df0b8970dd39a67f4f884b3f1e61e2e7a01ee77aaf526R78

Honeycomb keys are exported as snake case. This is a matter of preference and Im open to removing this being non-customizable, although the trend so far leans towards that in both our codebase and what's "suggested" by Honeycomb.

Example fields from precise-code-intel-worker, available @ https://github.com/sourcegraph/sourcegraph/pull/28040