nots: дедупликация действий после сборки, пропуск pnpm install на актуальных node_modules

## Суть изменений:

1. Пересмотрены методы логирования при сборке (и после), чтобы не показывались логи действий, который не выполняются (пропускаются).
   Таким образом логирование секций кода (с последующим стиранием строки лога) теперь осуществляется в методе-обёртке.
2. Команда `nots install` теперь выполняет последовательную сборку пиров (раньше запускал параллельно, что приводило к состоянию гонки);
3. Сборка пиров в команде `nots install` выполняется без рекурсивного обхода пиров для пиров (все пиры и так переданы). Это позволило не "чинить дедупликацию", а в принципе не приводить к "дупликации" – каждый пир проходится один раз. Тут важно определить порядок обхода.
4. Пропуск повторных запусков `pnpm install` без необходимости. Необходимость вычисляется так:
   - `builder` в локальном режиме кладет в аутпут файлик `pre.pnpm-lockfile.yaml`, хеш которого используется в `nots/cli`
   - `builder` в локальном режиме рядом с папкой `node_modules` создает файлик `node_modules.json` с хешом `pre.pnpm-lockfile.yaml`, который использовался при сборке этого `node_modules`
   - `nots/cli` использует сравнивает файлик из аутпута и из `node_modules.json` и если отличаются, то `pnpm install` запускается.

Пожалуй, пункт 4 стоит расписать.
Кажется, что эти файлики всегда будут совпадать, но я перестраховываюсь: часть пиров может быть закеширована в сборке, но удалена из `~/.nots/nm_store`, например, при запуске с `nots --clean`.
Чтобы избежать подобных локальных казусов я и перестраховываюсь.
Хеш от `pre.pnpm-lockfile.yaml` предпочтительнее хеша от `pnpm-lockfile.yaml`, т.к. он включает в себя пиры (т.е. это результат смерживания лок-файлов).
Также была версия с проверкой, что node_modules создалась в промежутке между проверкой и запуском nots/cli (т.е. в рамках `ya make`), но это не работает при кешировании узлов сборки пиров.
Если у вас будут идеи, какие еще проверки можно сделать для принятия решения, запускать ли `pnpm install` – я открыт к предложениям.

## Побочные улучшения:

### nots/cli

- Добавлен хелпер `utils.ts:processItems(items, action)` - отказоустойчивый `forEach`;
- Для `log-formatters.ts:unlog` вместо прямой записи ESC-последовательностей в stdout используется модуль `readline`;
- `log-formatters.ts:unlog` не срабатывает в тестах (пишет заглушку) и при включении отладочного вывода (`DEBUG`/`--verbose`);
- Для `DoneHandler` добавлен метод-обёртка  `runOnce(action, key, fn)` для более удобного использования, а также запись в лог отладки, если действие пропускается.

## Что не вошло в PR

Осталось на будущее:

1. Дедупликация пиров нескольких таргетов.
   Т.е. сборка пиров при `nots install project1 project2` должна быть общей, а не своё поддерево для каждого.
   И `ya make` для них нужно запускать один раз.
   И пост-сборочные действия выполнять единожды в правильном порядке, деже не пытаясь в дупликацию.
2. Подобный пункту 4 механизм, но не для `nots build`, а `nots install` — не запускать `pnpm install`, если недавно ставили (тут нужно определиться с критерием)
commit_hash:11f98acb44f759464876f61c5dbf69da7c0d0340

0 files changed, 0 insertions, 0 deletions