Add draft of what layout description might look like

[haltman-at]

OK, I finally sat down and banged this out. Attempts to address #31. Tried to cover everything that seemed reasonable. Did this primarily in prose rather than listing out object structures and field names and such, hope that's OK. Lot of uncertainty on a number of points but I hope despite that this is concrete enough to work with -- not to use I mean, but to work on without having to figure out any more fuzzy indefinite points, that the remaining questions are contained to discrete points.

(I guess there's perhaps one exception to this, which is the question of primitive types. Oh well.)

I think this does an OK job at all three goals? There's more I would maybe have liked to included to be more general but it didn't seem practical. I don't know, I'll let you all figure out whether some version of this should be included! Primarily I hope it at least shows that the problem is (or at least may be) solvable and we don't need to exclude this as entirely unworkable. :)

[cameel]

Pinging @frangio, who was interested in this topic.

[frangio]

Thanks. My interest was in making sure that the layout information of types (e.g. structs) was made available even if they are not used in state variables. In the draft in this PR I didn't see any mention of what types from the code would be included in the debug information for a contract. @haltman-at any thoughts on this?

[haltman-at]

Oh, geez, I just realized there's something big I left out: How things are pointed to on the stack. Actually, one could perhaps speak of cross-location pointers in general, but as that doesn't exist mostly at the moment, probably no sense in includng that; it's premature.

But, I guess something that needs to be added is, for each type, for the stack location, I talked about from/to but really we also need to say, does this thing live directly on the stack or is it pointed to. And if it's pointed to, we need to specify the pointer format -- do we just point to the start, or do we have start/length? And then if it's start/length we need to break down which part is the start and which part is the length... also, for length, we likely want to be able to specify what the length is measured in -- for instance it could potentially be "bytes" or "words" or "items".

(Yes this should be added to the PR itself but I don't have a lot of time at the moment)

[gnidan]

I've rebased this against the Docusaurus stuff, now in main, and instead of leaving this PR open with the various comments/concerns, I've added all of @cameel's notes/questions into the document itself.

Merging this now as a "prototype sketch" for review soon.