allow file extension mapping to be extensible when mapping to kinds

[rabbah]

the CLI hardcodes some file extensions which it maps to action kinds - this list should be extensible, in two ways: 1) allow a build to incorporate custom mappings, 2) allow wksprops to encode additional preferences.

[csantanapr]

+1, This would make it easy for me to add .sh --kind bash:4 and .pl --kind perl:5 (openwhisk/action-docker-v2) the new go loop prooxy :-)

[mdeuser]

should this be driven by the backend since it knows exactly what runtimes it supports?

[rabbah]

i'm not convinced yet that it should be a backend function although it would serve to normalize some of the extensions --- and in any case a client would need to fetch the runtime mapping and store them locally (because it would be wasteful to query the backend on every create/update operation for a mapping which is fairly static). Also some clients infer the kind without an extension (the ibm cloud ui for example).

[mdeuser]

sounds good. client would

• fetch the backend runtime support whenever the target openwhisk host changes. client would need to manage a local copy of this information for all other operations
• maintain the extensible file extension map; perhaps seeded/extended with the backend information
• fail --kind and file extension inferences that map to an unsupported runtime
• attempt to identify runtime when no file extension is present