Rationalize taxonomy of top-level Eden objects and reflect it in a CLI and its help

[rvs]

At this point Eden has grown quite a bit into, effectively, a system that manages various runtime and static objects to make different scenarios of working with EVE possible. These objects are:

1. Static objects:

   • Eden's own configs/contexts (current config subcommand)
   • EVE's controllers (current controller subcommand)
   • x509 certificates (current certs subcommand)
   • Edge Containers (current ociimage subcommand)
   • EVE live images (current eve-update subcommand)
   • Test suites/Test scripts (current test subcommand)

2. Dynamic objects:

   • Adam instances (current adam subcommand)
   • Redis instances (current redis subcommand)
   • Eserver instances (current eserver subcommand)
   • EVE instances (current eve subcommand)

On top of that we have what I would describe as top-level actions (those act on a collection of objects described in a current context):

• setup (makes sure that all of the local objects defined in my current context are up-to-date)
• clean (it actually isn't clear to me anymore what it does -- but logically it should probably an opposite of setup in a sense that it would clean any transient resources -- like disk space or docker cache that setup may have created)
• start (makes sure that all the dynamic objects get started)
• status (gives me a view of the objects currently known to Eden)
• stop (makes sure that all the dynamic objects get stopped)

Here's what I'd like to propose for the immediate (7-10 days future):

1. Research whether it would be possible to clearly format 3 different sections when eden prints its help (currently we're simply relying on Cobra to list commands in the alphabetical order).
2. kill server subcommand and move whatever functionality maybe left there under eserver
3. kill reconf subcommand and move whatever functionality maybe left to either `
4. rename ociimage to either eci or eci-image
5. rename eve-update to either baseos or eve-image and expand its scope (eventually to be able to manipulate various forms of EVE's baseos
6. move info and log top level subcommands under controller and model them after zcli by having a single eden controller events command and being able to filter the kind of event you're interested in by the --filter-type flag
7. Figure out what to do about clean top level subcommand, if you agree with my definition above

Note that #3 and #4 should probably go together (e.g. if it is eci-image it should probably be eve-image).

[mydatascience]

About configs:

Default configs are generated by default. Default config pattern is generated upon make build and stored in eden folder. Also the eden config add default command  is executed.
eden config add <name>  - adds the new config copied from default.  
    --file option - adds from file.
    If the config with <name> exists return that it already exists
eden config delete <name> - removes the config   Name is required.
eden config set <name> - sets the config to <name>.  Name is required.
eden config list  - displays the config
eden config get  <name> - gets the  config <name>.
    Omitted <name>- gets the current config 
    --all -gets the config from file
    --key - shows the param
eden start has the option of --config <name> or --config-file <path>