Add support for general info

[ghostbuster91]

This refers to #11

I am not sure about this duplication of classes (Info, Contact, Licence) since their purpose is only to hold information relevant for openApi. So they could live in openApi module and be provided as we convert endpoint to openApi structures.

On the other hand there is e.g. a root server structure which may affects the behavior of endpoints, so it will have to have a representation in tapir module.

I wonder whether we should keep parts of openApi structers only in relevant modules or to have consistent api with duplicates.

An example:

1. with duplicates

val endpoint: Endpoint = ....
val api = tapir.Api(info = ..., endpoints= ..., server = ...)  <- all those things live in tapir module
val openApi = api.toOpenAPI
val http4sRoute = endpoint.toHttp4s(api)

val endpoint: Endpoint = ....
val server = tapir.Server
val info = openapi.Info
val openApi = endpoint.toOpenapi(server, info)
val http4sRoute = endpoint.toHttp4s(server)

Update:
Since there can be multiple servers specified we always need to explicitly provide a particular instance.

[adamw]

I think I would avoid duplicates as long as possible - that is, once there's a really use-case for Api-like classes outside of documentation generation (be it openapi or not), let's leave them in the docs modules.

That might be also intersecting with softwaremill/sttp-apispec#4: to conveniently define the openapi metadata structures, you might need some builder methods/alternate constructors etc., which would directly yield e.g. OpenAPI, Info etc.

[adamw]

a może zostawić oba warianty: jeden z title: String, version: String i drugi z info: Info? Ten drugi by dawał pełną elastycznośc, pierwszy by zapewniał "szybką ścieżkę"?