fix(response): brings Response object to parity with Functions

[philnash]

I was checking the code behind the Response object that Functions uses and noticed some differences, such as:

• set/append functions returning this so that you can chain functions
• body is initialized as null not undefined
• being able to set headers, body and status code in the constructor

I think this brings the serverless toolkit version of the Response up to parity in both twilio-run and runtime-handler.

Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

• I acknowledge that all my contributions will be made under the project's license.

[dkundel]

Shouldn't the better test here be to re-check response because technically even though it returns itself we want to make sure it updated the original response object? This test would still succeed if we accidentally changed the logic where setStatusCode returns a new object

[dkundel]

and then have a dedicated test that calling the same function twice chained returns the same instance.

This really applies throughout the PR

[philnash]

I agree that this should have been a different test, that was lazy on my behalf 😄. I've updated that now.

I don't think we need to call this twice and test after though. Using expect(object1).toBe(object2) checks referential identity of the objects. So if we started returning a new object from setStatusCode, or the other functions here, this test would fail. Then the existing tests ensure that the changes are correctly made on the original object.