The idea behind optional results is that there may be instances where
each line of source code has many results and you don't want to annotate
all of them, but you still want to ensure that any annotations you do
have are correct.
This change makes that possible by exposing a new predicate
`hasOptionalResult`, which has the same signature as `hasResult`.
Results produced by `hasOptionalResult` will be matched against any
annotations, but the lack of a matching annotation will not cause a
failure.
We will use this in the inline tests for the API edge getASubclass,
because for each API path that uses getASubclass there is always a
shorter path that does not use it, and thus we can't use the normal
shortest-path matching approach that works for other API Graph tests.
I've been writing tests for crypto libraries in Python, and have wanted to write
code along the lines of
```py
md5.hash(b"some message") # $ HashInput=b"some message"
```
which didn't work before this commit, forcing me to store my text in a variable
like below. This turned out to be really annoying when dealing with more complex
examples, so therefore I'm adding this new functionality to allow this behavior.
```py
msg = b"some message"
md5.hash(msg) # $ HashInput=msg
```
In preparation for adding this to Python, I have split out the
definition of the comment class in a separate file (which will be
specific to each language).
