Schema rationalisation

[Marginal]

The currently in-use outfitting/1 and shipyard/1 schemas were designed before the Companion API was (semi-)supported by FDev, and the commodities/2 schema was designed for apps which obtained data via OCR. Therefore all three schemas were designed to transmit information using English-language text.

This has the side-effect that sending apps such as EDMC have been forced into the role of gatekeepers of the Companion API data; until the authors of the sending apps have figured out the correct "translation" of a token from the Companion API into English then the apps send information incorrectly or not at all. The authors of the sending apps are not necessarily best placed to figure out this "translation" since they only see a small subset of the available data.

This PR:

• Introduces new simplified schemas for outfitting and shipyard that send the FDev symbolic names from the Companion API directly instead of sending English names, classes and ratings. Here is a sample outfitting message in the new schema.

• Introduces a new schema for commodities that sends commodity names as they appear in the FDev Companion API instead of sending English names, and reports additional useful info:

  • meanPrice
  • statusFlags
  • additional stockBracket and demandBracket values

  Here is an example of a message in the new schema which illustrates this new info.

• Undoes PR Add FDev IDs - two proposals #42 including the sending of FDev integer IDs - I believe that the FDev symbolic names are more useful and, unlike numeric IDs, they are exposed in the forthcoming Journal.

Implications for senders:

• Sending apps no longer need to "translate" the data from the Companion API. This will make the data produced by sending apps more consistent and correct.
• Sending apps do still need to filter the data to only send the relevant properties and to skip Cmdr-specific items - see here for info.

Implications for listeners:

• Listeners must translate FDev symbolic names of modules and ships to displayable names. These tables are current and complete(?) for E:D 2.1.05: outfitting & shipyard, but expect to receive new items not yet in these tables once E:D 2.2 goes live.
• Listeners must translate commodity names as reported by the Companion API to displayable names. e.g. "Heliostatic Furnaces" -> "Microbial Furnaces". I believe that most listeners do this already given that they will have seen both "untranslated" and "translated" names in commodity/2 messages in the past. Here is a mapping of commodity names that require translation current for E:D 2.1.05.
• Listeners must handle new values 0 (not purchased) and "" (special) for the "demandBracket" property in commodity/3 messages, in addition to 1/2/3 (low/medium/high):
  • Listeners should force demand to null or zero when demandBracket==0. (Previously this was the sender's responsibility).
  • Listeners should discard the commodity when demandBracket=="". (Previously this was the sender's responsibility).
  • Listeners may use the content of the new "statusFlags" property to display a commodity with additional context and/or to retain a discarded commodity.
• Listeners must handle the new value 0 (not sold) for the "stockBracket" property in commodity/3 messages, in addition to 1/2/3 (low/medium/high):
  • Listeners may differentiate between stockBracket==0 (not sold) and (stockBracket==1 && stock==0) (currently out of stock).
• Listeners may use the new "meanPrice" property to update their average prices.