Response, IResponse: unified API (BC break)

[xificurk]

• bug fix / new feature? a bit of both
• BC break? yes
• doc PR: don't think it's needed

Response API at the moment slightly differs from IResponse. This PR unifies both APIs. Also, explicitly marking all nullable parameters as nullable in parameter type hint.

[xificurk]

@dg Any thoughts? I think this needs to be resolved before stable 3.0 version.

[dg]

?type $var = null is inconsistent with the rest of framework, where is only type $var = null.

[xificurk]

I always assumed this was a hack for declaring nullable parameters from pre 7.1 times.

[dg]

For PHP both declarations are identical. We can agree to change type $var = null => ?type $var = null in the whole framework, but I think it is unnecessary.

[xificurk]

OK, but 398dc22 is not enough, there is still a major incompatibility:
Response::setHeader(string $name, ?string $value) vs IResponse::setHeader(string $name, string $value), plus IResponse::deleteHeader() is completely missing.
And since it's currently not possible to require Response by specific type, it means there is no way to delete remove header.
That was actually the original motivation for this PR. I've got failing builds, at first because I was relying directly on Response, which was deprecated in #90. After replacing the specific implementation by interface, the build started to fail because static analysis (correctly) flagged calls IResponse::setHeader('Foo', null) or IResponse::deleteHeader('Foo') as an error.

[dg]

I understand where problem is and #147 is opened.

There will certainly be much more similar issues in Nette and I'll try to fix them in the next version.

[xificurk]

#147 revolves around IRequest vs Request API. This PR was about IResponse vs Response API, but the root cause is the same - BC break from #90.