(ci): include sort broken in child repositories

Description

Problem

In multiple repositories projects, the header includes sort is broken. In short, before sorting anything, we look for all the libs and modules of all repositories, because we want all sight-based includes to be on top of includes of other libraries.

To achieve that, in submodules, we rely on the following configuration:

• for the main project, the variable codingstyle-hook.additional-projects with the list of submodules should be defined
• for submodules, we just browse the parent folder

Over time, people have forgotten this configuration. When the variable codingstyle-hook.additional-projects is not set, the default is to start the search with the parent folder. On the CI, this works, but on a dev computer, this may fail because this could include other applications folder cloned at the same level (i.e. c:\dev\apps) and it will include stuff is should not. At the end of the day, the include may not be sorted the same way depending on the parent file tree, which is very wrong.

Fix

Now we consider that we only prioritize the libraries of the current repository in the includes sort. Thus, a child project will consider sight includes like any other 3rd part library. This simplifies a lot the process. The unit-test has been enriched to take that into account.

We also changed the way the root of the repository is searched. We used to rely on git-rev-parse, but this is a bit annoying for unit-testing. On top of that, when using sheldon -i, we use to fail to sort the includes if we do not run the command inside the repository. The new method proposes to look recursively and backwards a .sight file in the file tree.

Closes #48 (closed)

How to test it?

The unit test should be sufficient, but you can test to reformat some files in your preferred repository.

Additional tests/tasks to run

• You can also verify that now, you can run successfully sheldon -i outside of the repository where the file lies.
• Also you can notice that sheldon is now faster because we cache the repository root instead of calling git-rev-parse each time. On Windows, where sheldon is known to be very slow because of file access, on a run of 16s, sheldon now takes 10s.