Optimize Component and Complex form creation/validation

Describe the feature

The Crdt version of the Test CanSyncRandomEntry takes significantly longer than the fwdata version.

Here's the profiling data of the crdt version of the test with no round-trip API, which seems to confirm our suspicion that complex forms and components operations are quite expensive due to preventing reference cycles.
Profiling data was collected in Visual Studio by putting break points at the beginning and end of the test and using Record CPU Profile in the Diagnostic Tools view.
(Sadly I could not find a way to export any of the profiling results, but I've included lots of screenshots)

TLDR;
Checking for reference cycles or duplicate complex-forms/components accounts for approximately 1/5th of the entry sync time.

Summary of the test:

1. We create an entry with 5 of everything (senses, example-sentences, complex-forms, components etc.)
2. We make a significantly altered version of that entry:

• 5 new things of everything
• heavy modifications and deletions of everything

So:

• 5 components and 5 complex-forms are added
• components are moved around and some are deleted
• 5 senses and 25 example sentences are added
• existing senses and example sentences are shuffled and some are deleted

Bird's eye view

For profiling We focus only on the EntrySync.SyncFull(before, after, Api) code, because everything else is test infrastructure. (e.g. PrepareToCreateEntry).

SyncComplexFormsAndComponents and SyncWithoutComplexFormsAndComponents are almost equally expensive.
One would think that the former is significantly cheaper, because it only syncs 2 fields, but it's actually more expensive than syncing the entries and their children.

Sync without components

Senses are by far the most expensive step. That makes sense, because they're a tree of entities:

Senses

Time syncing senses is fairly evenly divided between: Add, Replace and Remove:

• Add: No specific bottleneck

• Replace: all the time is spend on example-sentences, because that's all we change on existing senses:

• Remove: nothing noteworthy

Sync with components

Almost all the time is spent on Components rather than Complex Forms:
(is that maybe simply, because we sync Components first? They both have to check for reference cycles.)

Components

Adding was by far the most expensive.
Looks like nothing was reordered, which is unexpected.

• Adding: basically all of the time is spent checking for reference cycles or duplicates in the database:

Flamegraph overview

Start with EntrySync.SyncFull(before, after, Api), comparing SyncComplexFormsAndComponents and SyncWithoutComplexFormsAndComponents, then use the CanSyncRandomEntry test and the profiling screenshots to locate the cycle or duplicate checks. Done means reducing the cost of component and complex-form synchronization while preserving the test's sync behavior.