Recreated bug with lineObjects being corrupted due to not accounting for $ref line numbers

[lobocv]

This is a PR that recreates the issue with a test
See the discussion of the original issue in vacuum.

TLDR: The doctor uses a data structure that maps line numbers to YAML objects, however the line numbers do not account for $ref, in particular, $ref to other YAML files. This causes multiple YAML objects to be mapped to the same line number, but the code only records the first object to come in from the concurrent processing of objects.

This results in non-deterministic results of the $path in the vacuum report and causes issues for people using that $path in ignore files.

I'm happy to help fix this but would need guidance on the best approach as I think it's not straight forward.

[daveshanley]

I think the key here is to change lineObjects to be a different design that encapsulates all mappings. We can then determine which path is correct based on the parent.

[daveshanley]

I am probably going to end up touching this code soon as I move the doctor into the next phase of its life with a new update that is coming soon.

[lobocv]

Excellent, then I'll hold off on exploring this further. The problem is well understood but the solution is challenging for me.

One more thing to consider when you come up with a solution. A line number may contain two parts (key and value). Right now I don't think lineObjects accounts for this. I think it always holds the value, but this is an issue for linting rules that run against the key. It can be solved by making the lineObjects map's value a tuple of (left, right) or something of the like