Декларативное определение библиотеки на основе структуры проекта

Взято по аналогии со стандартами разработки Go (https://github.com/golang-standards/project-layout)

Реализовать декларативное описание библиотеки на основании структуры проекта. Например:

• /cmd - определяет "ИсполняемыйФайл".
• /pkg (/public) - Классы и модули расположенные определяют публичные объекты аналогично "ОпределяетКласс"/"ОпределяетМодуль"
• /bin - регистрирует расположенные внутри аддины.
• /internal (/private) - включает в состав пакета, но не публикует классы/модули
• /vendor - включает в состав поставляемые библиотеки (текущий аналог oscript-modules)
• /docs, /examples, /etc ... - дополнительные файлы библиотеки (документация, примеры, другое)
• /tests - содержит тесты проекта. Тесты запускаются в едином с /public+/private контексте.

Для задания псевдонимов реализовать множественную аннотацию @Синоним/@Alias. Например:
/cmd/main.os - имя по умолчанию - создается cmd по имени библиотеки. Для

@Alias vrunner
@Alias runner

Или реализовать alias.json в папке с файлом:

{
   "main.os": [ "vrunner", "runner" ]
}

Аналогично, для публичных классов/модулей.

Это позволит:

1. Упростить описание проекта, полностью убрав, или разместив декларации объектов максимально приближенно к их определению
2. Сделает проекты более структурированными, что повысит их читаемость и сопровождаемость

Start by reviewing the current oscript-modules packaging behavior, then map how /cmd, /pkg or /public, /internal or /private, /bin, /vendor, /docs, /examples, /etc, and /tests should be interpreted. Compare the proposed @Alias annotation and alias.json approaches. Done means the project structure declaratively defines included and published objects, tests, extra files, and aliases without separate declarations.