Idiomatic Event Sourcing in Go

The previous implementation of serdes in the serdes package were going from Src to Dst (and back), where Dst is a "supporting" intermediary data structure. This however is a separate concern that can be split from the implementations.

This PR introduces the following changes:

1. A new serdes.Chain(), to chain two serdes together,
2. Change the serdes.* implementations to target a single type to byte-array instead.

After some time, golangci-lint is finally working ~well~ better with go.work files, which means we can finally enforce linter rules again (yay!)

This PR re-enables the linter, and fixes the complaints it has.

In order to provide a simple way to set common Metadata for a specific request/unit-of-work, this PR adds a eventstore.ContextMetadata to extend the request context.Context with the common Metadata, and an Event Store extension type, eventstore.ContextAware that appends this Metadata to each Domain Event appended using that context.Context.

With #59, I've noticed that some linting rules did not run and the code linting step passed successfully, although it shouldn't have.

Turns out that, since eventstore/postgres is in a different Go module, golangci-lint must be run in that folder explicitly.

This PR adds a new target to the Makefile, enumerating all the go.mod files and running golangci-lint in those folders.

This PR allows to wrap low level append function in Postgres EventStore implementation.

This would allow to execute some actions before or after the base implementation, things like extra validations, deduplication, mapping, etc. Also, the base function could be completely replaced with some custom code (like running a different SQL function or a different serializer).

What do you think about this idea @ar3s3ru? If it's ok, let me know if I need to update documentation or anything else.

This PR re-introduces support for subscription.Volatile, by adding support for a new Event Store interface: eventstore.SequenceNumberGetter.

With this interface, we can retrieve the latest sequence number value for the Event Store, and use a Catch-up Subscription that starts consuming from this value. Checkpoints should be disabled, as Volatile Subscriptions are meant not to carry state.

Sometimes it's desirable to specify inside a Projection whether the message being consumed should be checkpointed or not.

Example: projecting messages to a Kafka topic using batching -- if a whole batch fails, but we already committed the batch events processed in the Projection, then we need manual intervention.

This PR adds the following modifications:

1. projection.Runner creates some checkpointing information (*bool) and post it in the context for Projection.Apply to use it,
2. projection.Checkpoint(ctx), where the context set by projection.Runner specifies to checkpoint the current message if successful,
3. projection.DoNotCheckpoint(ctx), as above but without checkpointing.

Targets for the Event Store Stream operations were so far hardcoded (e.g. StreamAll, StreamByType, Stream).
This makes implementations and mocks a bit more verbose (due to the number of methods), but mainly more verbose to add additional targets for stream operations.

An example: streaming by multiple Event Stream types.

Normally, that would've required an additional method, and implementing the method for every implementation of eventstore.Streamer around.

However, we can simplify things and specify a sealed interface for representing Event Stream targets. So far, the supported targets are: All, By one Stream type, By multiple Stream types, By a single Stream ID.

The current logic to add events to Append telemetry data is broken.

Fix it by marshaling the incoming events to JSON and add it to the Span attributes.

I hate manual tagging because, as everything tasked to a human being, the human factor brings inherent error.

Since we're all ✨ software engineers here ✨ we can automate the tagging process when merging on main -- maybe after the tests have passed?

NOTE: for each feature, a minor release should be used, and fix or minor branch, a patch release should be used instead.