Scoped listings

[towerofnix]

Ooh, exciting! This pull request is a WIP.

Development:

• Resolves, or is towards, Per-group and per-album listings #395.

Details:

• Processes listings as real-deal live data objects, which are defined in a list of specifications. Those specs are internally a flat list and all listings are collected into one listingData object, but order matters (listing indexes reflect it), and the codebase is structured like a tree for ease of editing and maintaining the desired order.
  • This helps move data-relational code ("see also" reference resolving, for example) out of content functions and into property descriptors; graduates listings up from "kind of like an object, but not quite", which simplifies and brings common language to code surrounding listings in general; and lays the foundation for better data processing (discussed below).
  • Specs get a new scope property controlling which of the wiki data the listing runs on - discussed below!
  • Specs now include target explicitly, rather than implicitly computing it from the spec's directory.
  • Listing target specs are structured similarly. They basically do the same work as earlier, plus some goodies for data processing (discussed below).
• Generally moves data processing code, especially "querying" code, out of content functions and into the listing specs; these are defined with proper compositional property descriptors(!). There's a variety of new infrastructure to support this, but it's all based on existing building blocks.
  • These are mostly via a spec's data property, which is the standard entry point for getting stuff out of a listing. (Details of data value TBD, but it's probably always analogous to a content function's query.)
  • Listings can also define completely custom properties, inherit from from the target (used for getting easy access to albumData for example), and of course inherit from the main Listing constructor too.
• [Actual application of scope stuff TBD.]