bugc: give a storage mapping's pointer a template for its entry - #371

A storage mapping's pointer gave only the mapping's slot, so a debugger could not find players[alice] or its members from it. This gives the pointer a template for the mapping's entry, in the shape of the t_mapping templates that solc emits on its pointer-templates PR (argotorg/solidity#16990).

For players: mapping<address, Player> at slot 4, the pointer is now a templates collection around the region at the mapping's slot:

{
  "templates": {
    "entry": {
      "expect": ["slot", "key"],
      "for": {
        "define": {
          "slot": { "$keccak256": [{ "$wordsized": "key" }, { "$wordsized": "slot" }] }
        },
        "in": { "group": [{ "name": "value-score", "...": "..." }, "..."] }
      }
    }
  },
  "in": { "location": "storage", "slot": 4 }
}

As in solc, the template expects slot (the mapping's slot) and key, and the entry is at keccak256(key . slot), each a word. A value type there is a region named value; a struct's members are named value-<member> (value-score, value-combo, ...), with their offsets in the entry's slots as at a variable's own slot. A debugger reads players[k] with { templates, in: { define: { slot: 4, key: k }, in: { template: "entry" } } }.

bugc has no info/resources to hold templates, so they sit in the variable's own pointer, all in one templates collection at its root, and are named by the mapping's place instead of by a type id: entry for a mapping variable, <name>-entry for a mapping member name, and value-entry for a mapping in an entry (value-value-entry two deep). For a nested mapping, the outer entry's value region is the inner mapping's slot, which is the slot for the inner template.

A string member in an entry uses #369's generator with the value- prefix, so players[k].name resolves end to end as value-name-data (the name solc's templates give it too). #369's test read a mapping entry by calling the generator directly; it now reads it through the template.

The test runs a contract with mapping<address, Player> (a string member), mapping<address, uint256> and mapping<address, mapping<uint256, uint8>> at levels 0 to 3, stores entries for three keys (one name long enough for the long form), and resolves each entry with @ethdebug/pointers against the storage. This is debug info only: the bytecode of every example, of the test contract and of the Arcade demo contract is the same as before at levels 0 to 3.