inefficiencies and issues with the actions CRUD API

Actions are represented by the type `WhiskAction`, which includes a property of type `Exec`. The `Exec` instances may include the code inline. The REST API allows the controller to ignore the `Exec` value for the most part, but the current implementation has parallel types `WhiskActionMetadata` and `ExecMetadata` to explicitly drop the `Exec` values.

There is a lot of redundancy in the code - and the two types have drifted and changes are in one type and not the other. There is at least one bug that I'm aware of because of the drift.

Thanks to @chetanmeh's work, we do have uniform support for attaching "code" as separate entities (CouchDB attachments, S3, etc.). The implementation also allows for inlined code up to a certain limit. Because of these changes, we can drop the parallel types and improve the CRUD API's performance.

1. a GET of an action via the REST api today returns a butchered `exec` field with no code... is it OK to actually return the internal representation of the "code" attachment or do we continue to hide it?
1. is it ok to cache inlined code (since they are soft references and can be gced from the cache)?
1. all runtimes should be using attachments in the runtimes manifest, and so we should remove the property for "attachment" from the runtimes manifest
1. action operations continue to fetch the attachment and inline it (... only to discard it later for the "metadata" classes), this is unnecessary overhead