Make CI checks to always merge into current main/master

[alfsb]

This PR recreates CI tests, using plain git, instead of Github actions/checkout, that ignores changes on the main/master in checkout step, only in the checkout of repository related to the PR. Because of that, CI results are almost always outdated or invalid in busy repositories.

[alfsb]

Novas alterações enviadas no main/master, é possível re-testar a implementação. Antes de re-rodar os workflows, os hashes computados para os manuais gerados eram:

83feb956db564741733c1b69cec02cc59a994d5e  doc-base/temp/manual.xml
83feb956db564741733c1b69cec02cc59a994d5e  doc-base/temp/manual.xml

e depois

0e9bc8f1d383c1732dd5d34f54f635a8371b09a1  doc-base/temp/manual.xml
b860020de2783afce3c728eed35409f7441969d5  doc-base/temp/manual.xml

Onde é possível observar que, sim, a nova implementação não só conseguiu fazer o merge corretamente, como gerou um estado diferente dos arquivos. A seguir, vou encaminhar mais uma alteração, que tenta minimizar a implementação, que está muito longa.

[alfsb]

Novamente, desculpe pelo ruído. Refiz a versão em um arquivo separado, para facilitar comparação e implantação. Eu planejo esperar um pouco, até que o ramo padrão receba atualizações, e confirmar que a implementação alternativa gera resultados idênticos. Daí um último push remove o arquivo antigo.

[alfsb]

Antes do re-run:

Merge 7780dba7a041af478bc9be4a206bec7ecbcdf6b5 into d4429c51d33261cd7be1d6622e44da7212e7ba05
Merge 7780dba7a041af478bc9be4a206bec7ecbcdf6b5 into d4429c51d33261cd7be1d6622e44da7212e7ba05

Depois do re-run:

Merge 7780dba7a041af478bc9be4a206bec7ecbcdf6b5 into d4429c51d33261cd7be1d6622e44da7212e7ba05
Merge 7780dba7a041af478bc9be4a206bec7ecbcdf6b5 into 4f56d9bd843f63b3703953dec086b3a8b94fdca6

Então agora sim, funcionando a contento. Não é a implementação mais bonita ou mais geral, mas acredito que é a mais rápida para repositórios "pequenos", como é o caso aqui.

O problema geral é que a referência criada pelo GitHub (que fica presa no passado), é clonada com um --depth=1, então ela não contém nenhum dado de "navegação" dentro do banco de dados local do git. É preciso portanto baixar os dados históricos do PR e do main/master, até o ponto de ramificação em comum. Mas sem dados de navegação localmente, não é possível calcular esse ponto ou sua profundidade, e o git não tem um comando para calcular esse ponto remotamente, de forma que sobra apenas baixar os dados em lotes crescentes, até conseguir calcular o ponto comum, ou de baixar todo o histórico, filtrado ou não, e daí fazer o merge.