[ezequielzacca]

This PR's own change: compare with #836. The diff of this PR also holds every earlier step of #815, since a PR from a fork can only target this repository's branches.

Summary

The follow-up promised in #824's review (the comment): resolving the tooltip's condition and placeholder names when the files load, so drawing a tooltip compares no names and allocates nothing. Stacked last, on #836: every step of #815 changes the layout code, so this goes on top of all of them in one pass instead of being redone at each step. Only the last commit, perf(items): resolve tooltip condition and placeholder names at load, is this change.

RenderItemInfo rebuilds the tooltip every frame it shows. Every layout, description and name line found its conditions and placeholders by name: string comparisons through the value tables, then per shown line a std::function, a std::string and a std::wstring (CODING_RULES.md §12). The name lines also run for the windows and ground labels.

How

• Conditions: a condition keeps the value or state its name means (TooltipValue, TooltipState), resolved by ReadTooltipCondition. Checking one is a switch. The name stays for writing the file and for the editor.
• Placeholders: a line's text is compiled once per language into literal pieces and resolved placeholders: a built-in value, a stat file table, a skill or a monster, or the item's level values (resolved per level in the line's language). Engine/Object/ItemTooltipText keeps the compiled texts until the item data, the stat file or the tooltip file changes (ItemDatabase::GetVersion, which SetTooltipFile now bumps too). A compiled text keeps its source and bindings, so a text changed in place is compiled again.
• Writing: the layout lines go straight into the tooltip's rows (TextList); the name and description lines into a stack buffer. A placeholder that names nothing, or a text with a stray brace, stays as written from there on, as FillPlaceholders did.
• Values: ComputeItemTooltipValues no longer allocates. The item's name points at its data, and the add option's duration text is cached by its time.

GetItemTooltipValue, GetItemTooltipText and GetItemTooltipState keep their by-name overloads for the tests and the editor; they resolve the name first.

What stays

• A description still wraps into strings (WrapTextToWidth), as before feat(items): the tooltip's stat lines come from a tooltip layout #824.
• A name line still returns its name as a std::wstring; it's built from the stack buffer.

Tests

• Every item's tooltip is unchanged: the recorded snapshot passes as it is.
• New, test_item_tooltip_text.cpp:
  • built-in values, {level} and bound placeholders;
  • tables at several levels;
  • level values, and a level past them;
  • a placeholder that names nothing and stray braces;
  • cutting at the row's end;
  • compiling again after a version change.
• The tests that built conditions by hand now resolve them, as reading does.

Screenshots

This PR's build, for a level 400 Dark Knight. The tooltips look as on #836, since only how they're built changed.

Divine Sword of Archangel +15

Layout lines: damage, speed, durability and requirements, with their colors; the skill line's mana (skillMana).

Legacy theme	Modern theme

Dragon Knight Armor +15

Layout lines: defense, durability and requirements.

Legacy theme	Modern theme

Wing of Storm +15

Description lines with stat file tables at the item's level ({table:...}).

Legacy theme	Modern theme

Horn of Fenrir

A name line ("+Illusion" by excellentFlags) and its life.

Legacy theme	Modern theme

Large Healing Potion ×3

A shared text with a condition (@numberOfItems, when: [durability]).

Legacy theme	Modern theme

Orb of Rageful Blow

Requirements of a skill orb.

Legacy theme	Modern theme

Guardian Angel

A pet's description and life.

Legacy theme	Modern theme

Wizards Ring

Description lines and durability.

Legacy theme	Modern theme

Related issues

Follows #824's review. Builds on #836, #835, #834, #833, #830, #829, #828, #827, #825 and #824 (#815).

Checklist

• I have read and followed docs/CODING_RULES.md.
• I have built the project locally (see docs/build/README.md).
  • Windows x64 Release with the editor and the control socket: all 1322 tests pass, test_item_database_files in three random orders; the quality gate passes.
• Changes are focused on one concern; the diff is as small as it reasonably can be.