Feature Request: Preserve data augmented on thrown errors.

Consider a deliberated error thrown from a job:
```
queue.process('oupsy', function(job, done) {
const start = Date.now()
dal.getSomething( job.data.id, (e, res) {
if (e) {
e.duration = Date.now() - start;
if (e.code == 4007) e.foo = 'bar';
return done(e);
}

//use result `res` for whatever...
done()
})
})
```

In the current form, the queue preseves on the job data only `.error` probably as `e.stack`, which is accessible for future analysis.

BUT - we lose the data augmented on the error.
In the example above - it's `e.code` provided by `dal`, and `e.duration` and `e.foo` leyed by the job consumer, or any augmented error data - like `request/request` provides `code`, `statusCode`, and more - which are all lost... 😢

So,
I can suggest what's done in other systems I work with, which is in the sprit of:
`job.error = Object.assign( { message: e.message, stack: e.stack.split("\n") }, e)`
which basically pulls the non-enumerable message and stack, and adds to them every augmented enumerable attribute found on the error instance - including `e.code`, `e.foo`, `e.duration` and whatever.

**Added line:**, oh, right, we split the stack trace by `"\n"` - which makes it easier to read from a simply beautified JSON, we don't have to do that if the UIs will facilitate it seamlessly

But - I'm not sure if to start such a PR, because it changes the type of `job.error` from `string` to `Object`

Alternatively - we could preserve all the error data on a different job attribute, and the UIs will have to gradually stat using it.

Thoughts? Directions? Leads?

Start by tracing the queue.process error path to where job.error is stored, then inspect consumers of its current string form. Resolve whether the result should be an object or a separate attribute, and verify that augmented enumerable fields plus message and stack survive persistence without breaking existing readers.

Written by the indexing model from the issue text.