feat: handle nullish response types

[LeandroPereiraDaCruz]

This merge request addresses an issue that was wrongly opened in the elysia repository: elysiajs/elysia#124

Using responses types like t.Void(), t.Undefined() or t.Null() means that in fact there will be no content in the response.
It could happen in a scenario of status code 204, when no respose is expected.

But current behaviour is breaking the view, since it generates a response with a content that is not acceptable by swagger:

An example:
Code:

{
    body: "ActivationUserRequest",
    response: {
      200: t.Void({
        description: "User account was activated successfully",
      }),
      404: t.Void({
        description: "Pending account confirmation was not found",
      }),
      409: t.Void({
        description: "Account was already confirmed",
      }),
    },
    detail: {
      description:
        "Activate a user account based on previous secret that was sent by email",
      tags: ["User"],
      summary: "Activate a user account",
    },
  }

Screen with current behavior:

Screen with desirable behaviour:

[brunoeduardodev]

hmm, when I'm working with values that can be string | null for example, I usually create an union between t.Null() and t.String()

t.Union([t.Null(), t.String()])

but having a helper package to do it would be very helpful