Refine CLI core structure

[ic4-y]

Right now the CLI core structure as described in the readme appears to be lacking some core commands. In addition to that it should be more intuitive around certain basic user stories / use cases. This issue this meant to discuss refinement of core CLI structure.

Tow ideas:

1) On Core Eka Commands

• add an init subcommand to initialized a new eka-managed project. Potential flags might be used to create a git repository, and set the backend (which by default will be Nix anyways). It might also set a builder API endpoint, with localhost being the obvious default

# Local intialization
eka init --create-repo --backend=nix-lang --endpoint=builder-1.ekala.org
# Getting a template
eka init --from=url-to-template

Instead of specifying all these options via flags, the user might be guided through a few interactive questions when running eka init, depending on which flags are left unspecified.

A nice example of how guided questions might look like: https://nextjs.org/docs/pages/api-reference/create-next-app

Otherwise one might implement a shortcut like eka init --default to directly initialize a project with sane defaults.

Also we need emojis for nerd fonts. To put the 🦀 into the 📦 for our shiny ✨ new CLI tool 🔨 using Nix ❄️

2) On so-called Reification Commands

Typically "reifications" might include building of packages, applying of configuration for or creating shells. It might be a nice to specify the kind of thing we want to get, in case the project has multiple, and the destination or target where we want to have to available. There might also be a case where we want to build, but not deploy anywhere, i.e. something like --build-only

# For getting a package available on your current machine
eka apply package_name --target=localhost
# For a deploymenty on the local net with a local builder over ssh
eka apply os.hostname --target=ssh://192.168.1.125 --ssh-options="-i ~/.ssh/mykeyfile -p 2525"
# For managing home enviroment / userspace 
eka apply home.username --target=ssh://192.168.1.125
# For remote deployments of OS configurations
eka apply os.hostname --target=www.ekala.org
# For getting a local shell
eka apply shell.shellName

If we want to get semantically creative we could go unify instead of apply or something. But sematic creativity comes at the price of recognizability of commands.

Anyways, just a few thoughts, let's have a discussion!