Feature/status check handler

[AlexFBP]

• Se complementó el statusCheck con un nuevo check alternativo que acepta y llama a una función "handler" externa que se encarga del healthCheck
• Dicho handler puede incluso "romperse" y será capturado cuando se llame. Solo si el handler retorna nil se entenderá que todo va bien
• Es un cambio incremental, no "rompe" el funcionamiento de otros paquetes que actualmente usen Init()
• Se agregó un README para explicar el uso y ejemplos de uso

NOTA: Antes de fusionar, confirmar si esto es suficiente para que se considere fallido el statusCheck y/o si hay que ajustarlo https://github.com/udistrital/utils_oas/blob/e87de53fc1058fe5afac581d7dda1ee231752ecd/apiStatusLib/apistatus.go#L18-L20

Lo anterior actualmente retornaría, por ejemplo, si el handler retornara "Base de datos caída":

{
  "Status": "ERROR: Base de datos caída"
}

Una vez se confirme y/o ajuste, y para evitar hacer un nuevo PR; se podría quitar el estado Draft

De acuerdo a lo conversado con @fernandotower , basta con retornar un código HTTP distinto de 200 durante más de 3 ping para que se reinicie el servicio

[AlexFBP]

De acuerdo a lo siguiente (a la fecha de este comentario) https://github.com/udistrital/utils_oas/blob/1a06b62369f447a56f0e867d1fee26e81803dbd1/apiStatusLib/apistatus.go#L19-L21 ya se retorna algo similar a lo mostrado en el paso 6 (más abajo)

Para probarlo:

1. Se usó configuración_crud en local, importando utils_oas también en local. Cambiando el go.mod provisionalmente, agregando esto al final:

2. Se creó un handler para el status/health check, que basicamente lo que hace es consultar si una petición a una de las tablas originales: (Se abrirá otro PR para lo que tenga que ver con configuracion_api) (El logs.Error() no es necesario en el handler, ya internamente se llama a logs.Critical() con el error retornado por el callback (o por el panic() capturado )

3. Se registró el handler en el main.go

4. Se puso a ejecutar el crud, estando la DB activa

5. Una vez reportado el http server Running on http://:8080 se probó que fuera el mismo funcionamiento de siempre con GET / ({Status: Ok})

6. Después de lo anterior, se detuvo el servidor postgresql y se solicitó nuevamente el GET /, para obtener la siguiente respuesta

7. Se habilitó nuevamente el servidor postgresql y el {Status: Ok} volvió ante un nuevo GET /

Logs de los pasos 5-7 (Nótese tanto el UNHEALTHY_STATE como el [C])