Feedback for discussion

## Operations:
- follow a convention in branch naming (improve on potential contributors accessibility);
- ~~`main` instead of `stable` and `dev` instead of `unstable`~~;
- 🤝 Keep `stable` and `unstable` which will serve purpose of `main` and `dev`
- `release/x.x.x` branch to `stable` (similar to gitflow)
- small change: trunk commit to `unstable`
- bigger features/changes: feature branch to `unstable`
- code formatting / IDE support / lint to follow a convention;
- figure out a middle ground that will ease PR reviews and contributions and at the same time will not introduce mental burden on core contributors;
- 🤝 include `.editor.config` for `JS` and `Rust`
- tag experimental stuff with some `experimental` label and leave it aside from the main stable product until its usable and stable enough :D;
- cleanup deployment procedures and clear definition on release process and versioning;
- housekeeping on old issues;

## Architecture:
- composable or derive - agree on one and follow on;
- export * ?
- creates instead submodules

## Strategic discussion:
- where should fadroma head to;
- core feature set;
- discuss Rust / JS parts;
- UX (https://github.com/hackbg/fadroma/issues/92);
- integrations with other tools and workflows (e.g. cw boilerplates and other tools).