Fix AUR dependency resolving

[smolx]

Before this fix dependencies for AUR targets were added to the graph after each addition of a target node. Now dependencies are added only after all target nodes are added to the graph.

Also added some tests for previously bugged cases.

Fixes #2157.

[smolx]

I had the audacity to propose my solution to the issue.
Perhaps new and existing related methods could be named better. And there are definitely other things to improve.

I also found a similar pattern of dependency resolving in the GraphFromSrcInfo method. Maybe it should be fixed too. I haven't dug in it yet.

[Jguer]

From a first read it seems correct.

I had a doubt if it was working for recursive AUR dependencies but I haven't tried it out locally yet.

How does it handle yay -Syu ros-melodic-desktop?

The exists check that was removed had as an objective to prevent the computation of the dep graph for the same AUR package from repeating on each dependency layer

[smolx]

With this fix there is a significant difference only for cases with multiple targets, since it doesn't affect the recursive part.

yay -Syu ros-melodic-desktop and yay -S ros-melodic-desktop are handled well:

Sync Make Dependency (16)
Sync Dependency (18)
AUR Explicit (1)
AUR Dependency (136)
AUR Make Dependency (66)

It gives more or less the same result as the next branch. "More or less" is because amount of make and regular dependencies change on each run, even on the next branch. :)

The exists check that was removed had as an objective to prevent the computation of the dep graph for the same AUR package from repeating on each dependency layer

If I figured it out correctly, repeated computation during recursive traversal is prevented completely in the Grapher.addNodes method. So that removed check would help(in combination with this fix) only with cases of duplicate targets. Though performance effect is minimal. Target duplicates could be filtered out much more earlier.

[Jguer]

Still very happy to see this implemented. Let's merge it in

[Jguer]

I also found a similar pattern of dependency resolving in the GraphFromSrcInfo method. Maybe it should be fixed too. I haven't dug in it yet.

GraphFromSrcInfo has some low hanging fruit to fix if I remember correctly.