Using ECS to track the source of errors or exceptions

I'd like to discuss the use case of tracking the source of program errors / exceptions (line numbers, function names, etc) with ECS. These fields may end up under the field sets `file` and/or `error`.

I'd like to get feedback on how we could approach this. Information we may like to track about where the error was raised:

* error source file
* line number
* error message
* function/method name
* class / module (or other structure) inside which that function/method lives, when appropriate
* error class / standardized name (e.g. literally the class name in an OO language)
* error fields, if any
* error stack trace

Please let me know if there's anything I'm missing in terms of relevant data to support.

Here's a suggestion of a mapping for the above:

* error source file: [file.path](https://github.com/elastic/ecs#user-content-file.path)
* `error.line` (`long`)
* `error.message` (`text`)
* `error.function` (`keyword`)
* the word function is a bit more broad than `method`, IMO, so can serve both use cases.
* Error class: [error.id](https://github.com/elastic/ecs#user-content-error.id)
* Error fields
* Either create a field similar to [labels](https://github.com/elastic/ecs#user-content-labels), where people nest their kv attributes or we don't add it to ECS at first.
* stack trace: `error.stack_trace` (non indexed)

* @graphaelli or @roncohen I'd like your POV on how you're doing it currently in APM
* @ruflin I'd like your opinion on this as well

Start with the existing file.path and error.id definitions linked in the issue, then read the 21-comment discussion for any agreed direction. Done would require a settled ECS mapping for the proposed error-source fields and a documented decision on fields such as nested error attributes and stack traces.

Written by the indexing model from the issue text.