Sort output by components first

[fantazio]

Context

Currently, the output of the dead_code_analyzer is sorted lexicographic order in each report section, with an empty line in between directory changes. Below is a sample pseudo-output, copied from check/classic/classic.exp, with all the reports for unused exported values in examples/using_make :

./examples/using_make/advanced/inc_val.mli:1: x
./examples/using_make/advanced/inc_val.mli:2: y

./examples/using_make/bar.ml:1: x
./examples/using_make/bar_fn.ml:3: h
./examples/using_make/baz.mli:1: z
./examples/using_make/baz.mli:3: u
./examples/using_make/cond_sel.ml:13: h

./examples/using_make/dir/alias_opt.ml:7: y
./examples/using_make/dir/alias_opt.ml:14: x
./examples/using_make/dir/anon_call.ml:1: f
./examples/using_make/dir/anon_call.ml:5: g
./examples/using_make/dir/anon_call.ml:9: h
./examples/using_make/dir/anon_call2.ml:1: f
./examples/using_make/dir/anon_call2.ml:5: g
./examples/using_make/dir/anon_call2.ml:9: h
./examples/using_make/dir/match_opt.ml:8: l
./examples/using_make/dir/matchopt.ml:5: w
./examples/using_make/dir/mod.mli:10: M.f
./examples/using_make/dir/mod.mli:11: M.g
./examples/using_make/dir/refFn.mli:3: x
./examples/using_make/dir/ref_opt.ml:3: no
./examples/using_make/dir/ref_opt.ml:11: x

./examples/using_make/exported.mli:6: M1.five
./examples/using_make/exported.mli:10: F.plus_five
./examples/using_make/exported.mli:11: F.times_five
./examples/using_make/exported.mli:15: M2.five
./examples/using_make/exported.mli:16: M2.plus_five
./examples/using_make/exported.mli:17: M2.ten
./examples/using_make/foo.mli:2: y
./examples/using_make/fooFn.mli:2: g
./examples/using_make/functor.mli:2: M.f
./examples/using_make/functor.mli:3: M.none
./examples/using_make/functor.mli:7: F.g
./examples/using_make/functor.mli:11: N.g
./examples/using_make/let_in.ml:3: parent
./examples/using_make/let_test.ml:3: g
./examples/using_make/matchopt.ml:5: w
./examples/using_make/mod_alias.mli:2: M1.id
./examples/using_make/mod_alias.mli:6: M2.id

./examples/using_make/obj/class.mli:7: o
./examples/using_make/obj/class.mli:9: f
./examples/using_make/obj/inher.mli:11: o
./examples/using_make/obj/inher.mli:13: f

./examples/using_make/opt_in_opt.ml:7: x
./examples/using_make/qux.ml:1: z
./examples/using_make/unused_fn.ml:3: g
./examples/using_make/unused_fn.ml:5: var
./examples/using_make/useless_opt.ml:3: x
./examples/using_make/variant.mli:5: f

Because of the ordering, the reports acutally go back and forth between ./examples/using_make/ and its subdirs (advanced, dir, and obj).

Suggested solution

In practice, it would feel more natural to have a "component-focused" ordering at first, and within components use the lexicographical order. As a result, instead of the above, the reports would be ordered like below :

./examples/using_make/bar.ml:1: x
./examples/using_make/bar_fn.ml:3: h
./examples/using_make/baz.mli:1: z
./examples/using_make/baz.mli:3: u
./examples/using_make/cond_sel.ml:13: h
./examples/using_make/exported.mli:6: M1.five
./examples/using_make/exported.mli:10: F.plus_five
./examples/using_make/exported.mli:11: F.times_five
./examples/using_make/exported.mli:15: M2.five
./examples/using_make/exported.mli:16: M2.plus_five
./examples/using_make/exported.mli:17: M2.ten
./examples/using_make/foo.mli:2: y
./examples/using_make/fooFn.mli:2: g
./examples/using_make/functor.mli:2: M.f
./examples/using_make/functor.mli:3: M.none
./examples/using_make/functor.mli:7: F.g
./examples/using_make/functor.mli:11: N.g
./examples/using_make/let_in.ml:3: parent
./examples/using_make/let_test.ml:3: g
./examples/using_make/matchopt.ml:5: w
./examples/using_make/mod_alias.mli:2: M1.id
./examples/using_make/mod_alias.mli:6: M2.id
./examples/using_make/opt_in_opt.ml:7: x
./examples/using_make/qux.ml:1: z
./examples/using_make/unused_fn.ml:3: g
./examples/using_make/unused_fn.ml:5: var
./examples/using_make/useless_opt.ml:3: x
./examples/using_make/variant.mli:5: f

./examples/using_make/advanced/inc_val.mli:1: x
./examples/using_make/advanced/inc_val.mli:2: y

./examples/using_make/dir/alias_opt.ml:7: y
./examples/using_make/dir/alias_opt.ml:14: x
./examples/using_make/dir/anon_call.ml:1: f
./examples/using_make/dir/anon_call.ml:5: g
./examples/using_make/dir/anon_call.ml:9: h
./examples/using_make/dir/anon_call2.ml:1: f
./examples/using_make/dir/anon_call2.ml:5: g
./examples/using_make/dir/anon_call2.ml:9: h
./examples/using_make/dir/match_opt.ml:8: l
./examples/using_make/dir/matchopt.ml:5: w
./examples/using_make/dir/mod.mli:10: M.f
./examples/using_make/dir/mod.mli:11: M.g
./examples/using_make/dir/refFn.mli:3: x
./examples/using_make/dir/ref_opt.ml:3: no
./examples/using_make/dir/ref_opt.ml:11: x

./examples/using_make/obj/class.mli:7: o
./examples/using_make/obj/class.mli:9: f
./examples/using_make/obj/inher.mli:11: o
./examples/using_make/obj/inher.mli:13: f

I suggest printing the parent component's content before its children but do not have a strong opinion on that. Testing both parent-first and children-first on a few projects should provide better guidance.

When preparing the reports, the builddir is almost always available (for all all but styling issues). This is what would identify the "components".
For styling issues it is available when filling out the style list of reports.