implement oamctl functions described in Application Configuration

[wonderflow]

https://github.com/oam-dev/spec/blob/master/6.application_configuration.md#an-example-workflow

Install

$ oamctl install -c ./config.yaml ./frontend.yaml ./backend.yaml -p "message=overridden message!"

Discovery

$ oamctl trait-list
╔════════════╤═════════╤═════════════════════════════════════════════╗
║ NAME       │ VERSION │ PRIMITIVES                                  ║
╟────────────┼─────────┼─────────────────────────────────────────────╢
║ autoscaler │ 0.1.0   │ Server, Worker                              ║
╟────────────┼─────────┼─────────────────────────────────────────────╢
║ ingress    │ 0.1.0   │ SingletonServer, Server                     ║
╚════════════╧═════════╧═════════════════════════════════════════════╝

[wonderflow]

I've finished oamctl trait-list, I'm wondering do we really need a command like oamctl create -c ./config.yaml ./frontend.yaml ./backend.yaml -p "message=overridden message!"

Think further, implement oamctl create means we'll need to invoke API from OAM runtime. Now we have rudr which use K8s APIServer, what if another OAM runtime not using K8s APIServer? We may need to adapt lots APIServer unless we give a unified APIServer.

So I suggest use kubectl in the current time untill we have a different APIServer. In that time, we should consider should we make a unified APIServer including authorization, rest api for CRUD, etc..

@technosophos @suhuruli