Correct import paths for string-form refs to other generated serializers

[pixelblend]

Description 📖

This pull request fixes broken TypeScript import paths in generated files when a serializer uses a string-form type annotation (type "Foo", type "Foo[]", type "Record<string, Foo>") that names another generated serializer.

Background 📜

This was happening because Interface#used_imports resolves imports via two branches.

has_many :x, serializer: Y uses Y's known output pathname. But type "Y" in any form always joins Y onto config.relative_custom_types_dir (which defaults to output_dir.parent, i.e. types/), with no awareness that Y may itself be a generated serializer.

The resulting import lands one directory too high. At the top level this often goes unnoticed because a hand-written types/Y.d.ts can happen to exist. In a nested output file it creates an unresolvable path.

// app/frontend/types/serializers/Nested/SongSummary.ts
import type Song from '../../Song'
// broken: resolves to types/Song, which does not exist

The correct path is one parent up, landing on the sibling generated file:

import type Song from '../Song'
// sibling in types/serializers/

The Fix 🔨

Changed Interface#used_imports to first look up each extracted type name against the set of currently-loaded serializer interfaces: if it matches, use that serializer's output pathname (same resolution as the has_many branch). Otherwise fall back to custom_types_dir as before.

Added a new serializer and test to cover this case.

Please note, this changes the precedence rule for name collisions. Previously a string-form type reference was unconditionally routed through custom_types_dir, so a hand-written types/X.d.ts won over a generated types/serializers/X.ts when both existed. After this PR, generated serializers take precedence.

Screenshots 📷

Updated for the new serializer example.