The evils of emptyN

[JacquesCarette]

In 668bc55, @niazim3 correctly spotted a pattern, abstracted it out, and introduced emptyN in Language.Drasil.Chunk.Reqs for it.

But it, (somewhat like emptyS, in fact), is really bad [its use, not its abstraction]. When we have a field, we should fill it with something meaningful. If we consistently fill it with junk, then it means either

1. our design for that data-structure is flawed
2. our use of that concept is flawed

I believe that the problem here is actually a mixture of both!

ReqChunk is not about requirements at all. It is used merely to record module dependencies. Worse still: these dependencies are human-declared and not inferred! So there is not meaningful content to put in the NamedIdea of a ReqChunk because it isn't a "named idea".

[This actually points to a set of larger flaws we have, where what we declare as modules is completely independent of the modules generated. Furthermore, there is another disconnect where the requirements we declare are not really linked to the modules we declare. Traceability nightmare.]

[szymczdm]

Now that we've scrapped the original MG generation (and I just removed the last mentions of it from our examples in commit b9c17c9 ) I believe this one's fixed since ReqChunks are no longer actually in use and those were the only instances of "emptyN" (which has now been removed).

The rest of this issue will be handled by #430 and #417 (Module chunk generation), so I'm going to close this.