Missing response header X-Amz-Function-Error

I wasn't sure whether to open this here or over in https://github.com/aws/aws-lambda-nodejs-runtime-interface-client

With a simple example that always throws an error:

```Dockerfile
FROM public.ecr.aws/lambda/nodejs:12
RUN echo 'module.exports = { handler: () => { throw new Error("failure"); } }' > index.js
CMD ["index.handler"]
```

When I hit the endpoint:
```
$ curl -qv http://localhost:8080/2015-03-31/functions/function/invocations -d '{}'
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> POST /2015-03-31/functions/function/invocations HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 2
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 2 out of 2 bytes
< HTTP/1.1 200 OK
< Date: Mon, 18 Jan 2021 23:27:37 GMT
< Content-Length: 184
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
{"errorType":"Error","errorMessage":"failure","trace":["Error: failure"," at Runtime.handler (/var/task/index.js:1:43)"," at Runtime.handleOnce (/var/runtime/Runtime.js:66:25)"]}* Closing connection 0
$
```

As expected, the response payload has the shape described in https://docs.aws.amazon.com/lambda/latest/dg/nodejs-exceptions.html and the status is 200 to denote a function error.

However, shouldn't the response headers include `X-Amz-Function-Error` so that the error status can be determined without relying on heuristics?

Also, `Content-Type` should be `application/json`.

Start with the Dockerfile reproduction and the curl request to the local invocation endpoint. Verify the current response headers and payload, then trace the emulator's response handling; done means function errors include X-Amz-Function-Error and responses use application/json.

Written by the indexing model from the issue text.