Suporte a Paginação: Criação do Endpoint GET /exercise

Contexto
===

Atualmente na aplicação listamos os desafios, dificultado a limitação de 20 itens por pagina, porque cada candidata pode submeter de um a três exercícios por desafio.

Historia
===

Eu, como mentora avaliadora
Quero ver um número máximo de itens na listagem de Exercicios (20 Itens)
Para para não scrollar infinitamente e detonar meu computador esperando muitos anos para que listagem seja carregada (otimizar o tempo de carregamento)

Critérios
===

- Endpoint deve receber como query o parâmetro hiringProcessId e page (exemplo: /exercise?hiringProcessId={ID}&page={Pagina desejada})
- Deve se usar o hiringProcessId para filtrar os exercises ligados aquele hiringProcessId
- Deve ser paginado em 20 registros por pagina
- Deve ordenar por default por data de atualização (updatedAt)

Contrato API
===
Requisição:
```
GET /exercise?hiringProcessId=(ID)&page=(Pagina desejada)
```

Resposta:
```
{
"message": "Informações encontradas com sucesso.",
"data": {
"hiringProcessId": "2",
"exercises": {
(Lista de Exercicios)
},
"count": (Numero de Registros encontrados)
}
```

Tarefas
===

- Criar endpoint GET /exercise
- Implementar o suporte a paginação no endpoint GET /exercise

Notas Técnicas
===

- Atualmente os exercises não tem um relacionamento com hiringProcess, então é necessário criar uma chave estrangeira em exercise com a tabela hiringProcess

Documentação Técnica
===

Documentação TypeORM https://orkhan.gitbook.io/typeorm/docs/find-optionset=20
Documentação TypeORM https://orkhan.gitbook.io/typeorm/docs/find-options

Start at the existing exercise listing and the GET /exercise entry point, then read the TypeORM find-options documentation linked in the issue. Done means the endpoint filters by hiringProcessId, returns 20 exercises per page ordered by updatedAt, follows the stated response contract, and persists the required hiringProcess relationship.

Vom Indexierungsmodell aus dem Issue-Text verfasst.