Introduce package event with a dispatcher subsystem. Add this to the
manager and to the plugin subsystem.

Whenever the plugin subsystem execute a PostHook, we dispatch an
Change event on the event dispatcher bus. This currently has no
effect, but allows us to register subsystems on the event bus for
further processing. In particular, search.

By design, we opt to hook the plugin system and pass to the event bus
for now. One, it makes it easier to remove again, and two, the context
handling inside the plugin subsystem doesn't want to live on the
other side of an event bus.

While here, write a test for the dispatcher code.

The rollup service turns events into batches for processing. The search
engine wraps the rollup engine, making it private to the search
subsystem.

Add a search experiment to the code:

Schema in GraphQL is extended with an early search system.

Engine is extended with search, and gets passed through the resolver.

Some conversion is currently done to glue things together, but that
structure is ugly and needs some improvementificationism.

In go 1.18 strings.Cut becomes a reality. However, since it is such
a useful tool, add it to the utils package for now. Once we are on
go 1.18, we can replace utils.Cut with strings.Cut

This is almost not needed, but to be safe, add the ability to protect
changes to the engine, and lock most usage via an RLock().

Search results are Connection objects. Wrap each result in a contextual
object. This can be used for scoring/highligting/facets later.

Introduce interface SearchResultItem. Implement the interface for
models.Scene. Add hydration code for scenes.

Add scores into search results. Move Search-internal NodeIDs into the
search system.

Introduce search.Item which protects the rest of the system against
search-specific structures. Simplify hydration since it can now use
search.Item.

This experiment tells us facets want to be an input type rather than
the current enum of predefined facets.

Reindexing of scenes at the moment, because that's what we have. The
core idea is fairly simple: batch-process a table, a 1000 entries
at a time, index them. Replace the data loader every 10 rounds
(10k entries) so it doesn't grow too big.

While reindexing is ongoing, the online changemap is still being built
in the background. If reindexing takes more than the timer ticker,
it will fire immediately after. If reindexing takes more than twice
the timer ticker, the ticker protects against this and only fires once.

It is really a set of changes. The map used to implement the set is an
implementation detail that shouldn't be part of the name.

Pull stat tracking outward. Set up a reporting ticker and use it for
reporting progress. This rolls up the log lines into something a bit
more comprehensible.

Change the schema to support performer searches. Performers are
SearchResultItems. Make the search type optional, default to searching
everything.

Enable hydration of performers.

Add performers to the data loader code.

Introduce a performer document for the search index.

Load performers before loading scenes, to utilize the dataloader
cache maximally.

When considering scenes, find the needed performers, and prime the
cache with them.

When processing scenes, denormalize the performer into the scene.

If we update performers, all scenes those performers are in should
also change. Push this in.

Currently, we over-apply on a full reindex, which can be fixed later,
perhaps by moving preprocessing upward, or by having a flag on the
batch processing layer. It's plenty fast right now though.

Plug a hole with scenes that can be nil.

This change anticipates far better batch processing in the future.
By explicitly preprocessing, we can do this in the online processing
loop, but avoid it in the offline processing loop. This will avoid
processing elements twice.

Early tag support setup.

People will expect a tag to be fairly easy to grab. So prefer a direct
encoding over a nested subdocument. This allows a search for
`tag:woodworking` rather than `tag.name:woodworking`.

While here, add the tag ids into the scene document as well. This will
help with deletion.

Changesets will keep growing.

Implement Stringer formatting for event.Change.

Introduce engine_preprocess.go. Move preprocessing code into the engine
itself. Use the engine to pull data which needs a change on a performer
deletion. Rework changeset into changeset code only.

Code is a bit spammy at the moment with logging, but that will be
fixed at some point.

Introduce studios

* In data loading
* In search documents
* In changesets
* In the search path
* In the GraphQL schema

No functional indexing yet.

The strategy is to fold reindexing into a worklist which we
process through systematically. This reduces the full reindexer
into a single loop, which then collapses the code to a far simpler
code path, where the only variance is a switch on the document type.

Use this new strategy to handle studios as well for full reindexing.

Rather than having a single large function, split the work
into smaller functions and let the function names describe what
is being done. This should make the code more local and easier to
read.

Introduce indexing of studios in scenes.

Introduce documents.DocType to properly type the documents as an enum.

Facets are going to be a thing we add later on. An MVP doesn't need
facets, and we can remove lots of complexity if we don't have to worry
about them right now.

If a merge is called, we should process all sources and the destination.
Create an event ofr each of these.