[io] TDirectoryFile: propagate returnExistingDirectory to sub-calls and properly apply title

[silverweed]

Currently this doesn't work as expected:

auto dir1 = file->mkdir("a/b");
auto dir2 = file->mkdir("a/b", "", /* returnExisting = */ true); // should return the already-existing dir
EXPECT_EQ(dir1, dir2); // FAILS: dir2 is nullptr

because TDirectoryFile::mkdir doesn't propagate the value of returnExistingDirectory to recursive mkdir calls. This PR fixes it.

In addition, title was currently only applied to the topmost directory in case of hierarchies, which is counterintuitive as the returned TDirectory is actually the innermost. This PR changes the (previously undocumented) title logic to the opposite: every non-leaf directory gets created with a default title and only the innermost gets the user-defined one. In our codebase we have 0 cases of mkdir being called with a hierarchy and an explicit title, so this change shouldn't impact anything.

Checklist:

• tested changes locally
• updated the docs (if necessary)

[github-actions]

Test Results

    22 files      22 suites   4d 2h 29m 4s ⏱️
 3 780 tests  3 780 ✅ 0 💤 0 ❌
81 234 runs  81 234 ✅ 0 💤 0 ❌

Results for commit bcfe688.

[jblomer]

Shouldn't we rather use the empty string for the title of intermediate directories?

[silverweed]

Perhaps; the only reason I used the name as the title is because that's what the function does in the normal case when an empty title is passed (see line https://github.com/root-project/root/pull/20531/files#diff-56ce80e060312dead2b5c7965a71f7ddee4211abf448bee96240b3c908833e7eR1275).
But an empty title makes more sense to me as well.

[silverweed]

(but given the line linked above, even if I pass "" the effective title will be workname.Data(), so if we wanted actually empty titles we would have to change that)