Xeno arch balancing part 0

[Fildrance]

About the PR

Refactoring of XenoArtifact generation code towards new generation model. Accounts for possibility of generation code to return null (when failed to find fitting trigger or effect for node). And code cleanup.

Why / Balance

First step for implementation of balanced graph generation (so deeper nodes are more complex to get and are more valuable).
Design doc is here - space-wizards/docs#456

Technical details

Mostly code cleanup and additional checks if next code generation layer failed (returned empty resul). Collections allocation still is not great.
Removed a lot of unneeded 'ref' from code, replaced recursion in layer generation with cycle.
Replaced EntityTable with IWeightedRandomPrototype for effects - because picking them using table will not be possible when we will have 'budget range' and will need to dynamically restrict range of options. I am not sure its feasible / reasonable to try achieve it with EntityTables.

Media

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

XenoArtifactComponent.EffectsTable was replaced with EffectsWeights property, that uses new ProtoId<WeightedRandomXenoArchEffectPrototype>.
Replaced XenoArtifactEffectsDefaultTable with XenoArtifactEffectsDefaultTableBalanced and XenoArtifactEffectsHandheldOnlyTable with XenoArtifactEffectsDefaultTableBalancedHandheld.
SharedXenoArtifactSystem.CreateNode signature changed from

Entity<XenoArtifactNodeComponent> CreateNode(Entity<XenoArtifactComponent> ent, ProtoId<XenoArchTriggerPrototype> trigger, int depth = 0)

to

public Entity<XenoArtifactNodeComponent>? CreateNode(
        Entity<XenoArtifactComponent> ent,
        List<Entity<XenoArtifactNodeComponent>> directPredecessors,
        Dictionary<XenoArchTriggerPrototype, float> triggers,
        Dictionary<EntityPrototype, float> effects,
        int depth = 0
    )

Changelog

no

[iaada]

It actually is possible to do a dynamic cost system within entity tables, as demonstrated in #37783.

[Fildrance]

After analysis of mentioned PR i still am staying with current implementation.

My idea is that

1. triggers are prototypes, and they cannot use EntityTable
2. triggers are going to use BudgetRange to pick one.
3. triggers are going to have BudgetValue (actual value which trigger is going to represent. Even tho we can pick trigger by aiming at range, real value is kinda fixed, mostly in the middle of range but that depends...)
4. Effects are entities which are going to have BudgetRange
5. Effects also would have BudgetValue (because graph of artifact is interconnected and to pick next trigger we should use previous nodes as a starting position for picking up new ones)

So using Emo work we can put BudgetRange and its calculation into EntityTable related features, but the problem is withing BudgetValue - if we put it into EntityTable rule, we cannot get it out! Because output of EntityTable is... well, entities or entPrototypeIds. But we need both picked entity and actual value. And splitting this data between entity table and prototype itself sounds like a really bad idea, they are closely related :( I dont want to place BudgetValue in the middle of BudgetRange explicitly, and we wont have this data when EntityTable picks something too - so no point.

Its a mess but thats kinda how it rolls.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.