Feature flag

First of all, thank you for the excellent library. I enjoy using it a lot!

I'm working on a project starter module. It requires several other modules, such as `:kit/cljs`.

While I'm able to mostly get it to work, there are some features I miss.

## Passing feature flags to sub-modules

My meta-module requires `:kit/cljs`, among others. I'd like to be able to pass feature flags from the meta-module to select uix vs. reagent. For example `(kit/install-module :kit/starter {:kit/cljs {:feature-flag :uix}})`.

Would that syntax make sense or would you see it work in some other way? Would you be interested in a PR implementing it?

## Running extra commands after a module is installed

I'd like to be able to run commands (e.g. to install JavaScript dependencies) after my module is installed.

I'm currently dealing with that by generating a babashka task in bb.edn that self-removes itself after it succeeds (e.g. `bb kit-starter:setup`). But the user has to run it manually and even though `success-message` includes the instructions, it's easy to miss it in the output and I forgot to run it a few times myself.

I'd prefer there to be a way to define code to run after module is installed (a bb script perhaps?). It might be reasonable to always prompt the user.

What are your thoughts about that? Also, would you be interested in a PR?

### Example use-case for post-install commands

```edn
{:default
{:require-restart? true
:requires [:kit/cljs]
:success-message "**************************************************
Run: bb kit-karma:setup
**************************************************"
:actions
{:assets [["assets/karma.conf.js" "karma.conf.js"]
["assets/test/cljs/example_test.cljs" "test/cljs/<>/example_test.cljs"]]
:injections [{:type :edn
:path "shadow-cljs.edn"
:target [:source-paths]
:action :append
:value "test/cljs"}
{:type :edn
:path "shadow-cljs.edn"
:target [:builds]
:action :merge
:value {:test {:target :karma
:output-to "target/karma/test.js"}}}
{:type :edn
:path "bb.edn"
:target [:deps]
:action :merge
:value {dev.bilus/bb-oneshot {:mvn/version "0.1.0"}}}
{:type :edn
:path "bb.edn"
:target [:tasks :requires]
:action :append
:value [bilus.bb-oneshot :as oneshot]}
{:type :edn
:path "bb.edn"
:target [:tasks]
:action :merge
:value {clj:test {:doc "Run Clojure tests"
:task (clojure {:dir "."} "-M:test")}}}
{:type :edn
:path "bb.edn"
:target [:tasks]
:action :merge
:value {cljs:test {:doc "Run ClojureScript tests"
:task (do
(shell "npx" "shadow-cljs" "compile" "test")
(shell "npx" "karma" "start" "--single-run"))}}}
{:type :edn
:path "bb.edn"
:target [:tasks]
:action :merge
:value {test {:doc "Run all tests (Clojure and ClojureScript)"
:depends [clj:test cljs:test]}}}
{:type :edn
:path "bb.edn"
:target [:tasks]
:action :merge
:value {kit-karma:setup {:doc "Install karma dependencies (one-time setup)"
:task (do
(shell "npm" "install" "--save-dev" "karma" "karma-chrome-launcher" "karma-cljs-test")
(oneshot/remove-task! 'kit-karma:setup))}}}]}}}
```

`dev.bilus.oneshot` is a tiny library I put together for removing one-off tasks, their deps and requires, nothing fancy.

Start by reviewing the module installation API, especially the example `(kit/install-module :kit/starter ...)`, and inspect existing module definitions and actions. Clarify how nested feature flags and post-install commands should be represented; done requires an agreed design covering both requested capabilities and corresponding tests.

Written by the indexing model from the issue text.