Ruby: Fix spurious flow through reverse stores

[hvitved]

Commit-by-commit review is encouraged.

In Ruby, reads with known indices, such as

a[0]

give rise to two read steps; one that reads TSingletonContent(TKnownElementContent(0)) and one that reads TSingletonContent(TUnknownElementContent()) (if data is stored at an unknown index, it might be 0).

Since [] is just a method call, it means we have two flow summaries for []:

Argument[self].Argument[0] -> ReturnValue
Argument[self].Argument[?] -> ReturnValue

This works well for reads, however for reverse stores

a[0][1] = x

it means that we will get store steps into a with both TSingletonContent(TKnownElementContent(0)) and TSingletonContent(TUnknownElementContent()), which allows for spurious flow:

a[0][1] = x
sink(a[2][1]) # spurious flow

The solution in this PR is to add a new ContentSet branch

TKnownOrUnknownElementContent(Content::KnownElementContent c)

which can read from both TKnownElementContent(c) and TUnknownElementContent(), but which can only store into TKnownElementContent(c). We can then reduce a[0] to just a single read step, which reads from TKnownOrUnknownElementContent(TKnownElementContent(0)).

In order to distinguish TKnownOrUnknownElementContent(c) from TSingletonContent(TKnownElementContent(c)) in models-as-data specifications, we use the following syntax

MaD syntax	ContentSet
Element[0]	TKnownOrUnknownElementContent(0)
Element[0!]	TSingletonContent(TKnownElementContent(0))

and similarly for With(out)Element and ranges Element[0..]. This means that the flow summary for [] is just a single row:

Argument[self].Argument[0] -> ReturnValue

Note also that using Element[0] vs Element[0!] in output specifications makes no differences, since the former also stores only into TSingletonContent(TKnownElementContent(0)).

[asgerf]

LGTM. This conflicts with #10375 but it's probably easier for me to update my PR than the other way around, so feel free to merge first.

[hvitved]

This conflicts with #10375 but it's probably easier for me to update my PR than the other way around, so feel free to merge first.

Thanks. Sorry for introducing yet another merge conflict on your PR.