import-notation: Move to `bem-cell` API

[Yeti-or]

Right now import-notation operates with simple objects
we need to change it to bem-cell

[veged]

Анализ после миграции на 1.0.0

После #398 оригинальный кейс выглядит так:

import { parse } from '@bem/sdk.import-notation';

const cells = parse('b:button m:theme=normal');
// → [{ block: 'button' }, { block: 'button', mod: { name: 'theme', val: 'normal' } }]

Возвращаемая структура — массив локального BemCell интерфейса:

// packages/import-notation/src/index.ts
export interface BemEntityMod {
  name: string;
  val?: string | number | boolean;
}

export interface BemCell {
  block?: string;
  elem?: string;
  mod?: BemEntityMod;
  tech?: string;
}

Это не BemCell из @bem/sdk.cell — у того другая форма: { entity: BemEntityName, tech?, layer?, id? } + инстанс-методы (valueOf, toString, isEqual).

Стоит ли переезжать?

Сейчас @bem/sdk.import-notation — лист графа зависимостей: ноль внутренних @bem/sdk-deps. Переход на BemCell из cell-пакета даёт:

✅ Один и тот же BemCell во всех пакетах — можно прокидывать сразу в BemGraph.dependenciesOf, walk-walker'ы и т.п.
✅ Готовые методы: cell.id, cell.valueOf(), cell.isEqual(other).
✅ TypeScript-friendly — единый импорт типа.

❌ import-notation перестаёт быть листом: добавляются prod-deps на @bem/sdk.cell (которая тянет @bem/sdk.entity-name и далее по цепочке @bem/sdk.naming.entity.stringify + @bem/sdk.naming.presets). Bundle-size возрастает для проектов, которые сейчас тащат только import-notation.
❌ API breaking — потребители получают другую структуру результата. Уже на 1.0.0 — будет 2.0.0.
❌ parse() сейчас может вернуть entity без `block` (если scope не задан и в строке нет b:). У BemCell нет такой "пустой" формы — конструктор требует валидный entity. Придётся либо фильтровать на выходе, либо ослаблять конструктор BemCell.
❌ В тестах parse возвращает 2 сущности на b:button m:theme=normal: голый {block: 'button'} и {block, mod}. С точки зрения BemCell это два разных id — годится. Но семантика "первый = голый блок без модификатора, второй = с модификатором" работает только если потребитель уважает порядок. Это сейчас тест-инвариант, который придётся переносить аккуратно.

Рекомендация

Не делать жёсткий перевод. Лучше добавочный helper в существующем 1.x:

// new in @bem/sdk.import-notation
import { BemCell } from '@bem/sdk.cell'; // peer-dep, не runtime
export function parseToBemCells(
  importString: string,
  scope?: ParseScope,
): InstanceType<typeof BemCell>[];

— реализуется тривиально через существующий parse() + BemCell.create(). Получаем upgrade-путь без breaking change. @bem/sdk.cell добавляется как optional peer-dependency (т.е. требуется только если зовут parseToBemCells), чтобы import-notation не терял "лёгкий" режим.

Альтернатива — полный breaking перевод как часть будущей 2.0 (если соберётся набор других breaking-изменений), но в одиночку он не оправдан.

Что предлагается решить

1. Делать ли helper-форму (parseToBemCells) сейчас, в рамках 1.x. Я бы делал — небольшой объём, удобство для consumers очевидное.
2. Менять ли публичный default parse() на BemCell в будущей 2.0 — это уже задача дизайна 2.0.

Если решение по п.1 — да, могу сделать отдельным PR.