[DOCS] Explain rationale for lifting subdir notes out of hierarchy

[flyinggrizzly]

This PR adds documentation for the Directory Tree plugin explaining the rationale behind requiring that directory names be globally unique.

I started with your comment on the last PR, and tried to break it down and give more concrete detail. Hoping this works, and I'm more than happy to make changes to it.

[srid]

@flyinggrizzly This is good. Some comments:

• About the "work/notes" thing, to keep consistent with the previous example, let's start with the realistic ./My Home/Projects/House Warming/, and then introduce the ./Work/Projects/Launch missile. Then rename the former to "House projects" and the later to "Work projects".
  • We might even mention another example for creating non-directory folgezettel parent. i.e., create a top-level "Projects.md" that in turn branches to the two directory zettels (which illustratres linking to a directory zettel despite there not being a file on disk).
• Can we explain things in a simpler manner than the "lifted" terminology? The directory "hierarchy" is used here only to create folgezettel heterarchy, and is discarded otherwise. This is why a directory is treated the same as a .md file, i.e., the zettel ID is determined from its file/folder name (without regards to hierarchical path/location).
  • The programming/ruby example (.md input, and .html output) is still good, as a illustration.
• Since the guide is a Zettelkasten, you might consider to linking to other pages ([[id], [[web]], etc.)

[srid]

Note to self:

• explain the two goals behind creating the dirtree plugin as well as the "anti-goals" (see matrix link).
• create a new note, branching from philosophy, emphasizing the simplicity requirement of v2.0

[flyinggrizzly]

Hey sorry, I started this earlier today and then my computer died before I pushed 🙃

Still working on it, and I think your feedback is clear and should be easy to work with. I'll ping you when I've had a chance to get back at it (shouldn't be long).

[flyinggrizzly]

Alright--updated. They've gotten longer, though a lot of the length is from the repeated examples with file structures.

One thing worth looking at is the h4 towards the end--it makes sense semantically, but the default styles make it kind of small.

As usual, I'm more than happy to take feedback and make changes, so just let me know.

[srid]

@flyinggrizzly This looks pretty thorough, nice.

We can perfect it after introducing "best practices" section in the docs, and then moving some of the explanation in dirzettel over there as atomic zettels.