bugc: describe a storage string's encoding in its pointer - #369

Since #368, bugc stores a string or bytes value with Solidity's encoding, but its pointer still named only the slot. A debugger could not read the value from the pointer; it had to know the encoding itself.

The pointer now describes the encoding, in the same shape as solc's t_string_storage pointer template (and the "string storage allocation" example in ethdebug/format/pointer): a one-byte length-flag region at the slot's low byte, then a conditional on (length-flag + 1) % 2. When the flag is even, the data is a data region in the slot itself, length-flag / 2 bytes long. When it is odd, a long-length region covers the slot, and the data is a single data region from keccak256(slot), (long-length - 1) / 2 bytes long, across as many slots as it needs. This applies to top-level variables, struct members (with names qualified by the member, such as name-data), and array elements.

The new test compiles a program with a top-level string, a top-level bytes, a struct with string and bytes members, a fixed-size array of strings, and a mapping to that struct. It runs the program, then reads each pointer with @ethdebug/pointers against the resulting storage and checks the exact bytes for lengths 0, 5, 31, 32 and 70 at optimization levels 0 to 3. A mapping's pointer still names only its slot, so the test checks the entry u[7] with the pointer that the struct type gets at the entry's slot.

This changes only debug information. The create and runtime bytecode of every example, plus two string-heavy test programs, at levels 0 to 3, are byte-for-byte the same before and after.