Document non-code casing conventions

There's currently a myriad of casing conventions without a single place that documents all of them. This makes it hard for plugins to maintain consistency. We should document these conventions and make sure that examples in documentation, example plugins and test plugins follow these conventions to avoid confusion.

Frontend app URL's / `appRoute` => snake_case

We should document that plugins should follow the convention of using snake_case for their app URL's.

Frontend `appId` => snake_case?

There doesn't seem to be a strong convention in existing code, but given that appRoute defaults to /app/${appId} it should probably be snake_case unless we change the default to something like /app/${toSnakeCase(appId)}.

Config keys => camelCase

New Config keys should be in camelCase until we refactor all config keys to snake_case in 8.0.0 https://github.com/elastic/kibana/issues/7444#issuecomment-562132579

PluginId => camelCase

We have a runtime warning, but not sure if we have documentation https://github.com/elastic/kibana/blob/7e328417ab891cce72df2b25bfa56b4119a2de3f/src/core/server/plugins/discovery/plugin_manifest_parser.ts#L119

API URL's and fields => snake_case

Already documented https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md#api-endpoints

Saved Object type names => snake_case

Most types use kebab-case but since the type name forms part of the saved objects API URLs (https://www.elastic.co/guide/en/kibana/master/saved-objects-api-get.html) a better convention would be to use snake_case. Note: Changing saved object type names is not supported at the moment and would be a breaking API change, so we should not change existing types.

elastic / kibana