Drop support for saving corpus definitions anywhere

[lukavdplas]

The unit tests and documentation make a point of this: corpus definitions can be saved anywhere in the file system; they do not need to be saved within the repository. I can see how this could be seen as a useful feature, but it's not how we use corpus definitions.

If you've ever tried writing a corpus definition outside of the repository: it's not fun. I-analyzer's Corpus class (and related classes, convenience functions, etc...) includes a LOT of functionality, so you either need to mess with importlib to import I-analyzer code from the actual repository, or you need to copy a huge amount of code.

Older I-analyzer code had a design philosophy to move more responsibility to individual corpus definitions, whereas we have lately been outfactoring more common functionality. On top of that, corpora just do more nowadays. I imagine an independent corpus class would have made more sense in the past, but it's not very practical now.

An advantage of not advertising this option is that it would make more sense to formulate the corpus setting as

CORPORA = {
   'parliament-netherlands': 'corpora.parliament.parliament-netherlands',
   'troonredes': 'corpora.troonredes.troonredes',
   # etc...
}

which is a lot more readable than the file path. Or perhaps we want to include the class name too, so corpora can have arbitrary names:

CORPORA = {
   'parliament-nl': 'corpora.parliament.parliament-netherlands.ParliamentNetherlands',
   'troonredes': 'corpora.troonredes.troonredes.Troonredes',
   # etc...
}

[BeritJanssen]

@jgonggrijp any thoughts? I remember you were an advocate of this functionality.

[jgonggrijp]

In a distant past, I envisioned "Super Texcavator" as a highly decentralized and extensible tool. In that vision, it made a lot of sense for it to accept corpus definitions from anywhere in the filesystem. However, the actual I-analyzer gradually became much more monolithic than I imagined it (still extensible, though). In the current situation, I agree that placing corpus definitions elsewhere in the file system does not make that much sense anymore.

#981 would bring the situation closer to how I originally envisioned it again. I think energy would be better invested in YAML-based corpus "import" (file read) than in holding on to the possibility to import Python-based corpus definitions from anywhere.

(In other words, I'm not opposed to dropping support as suggested here.)