Fix a couple of bugs in type inference

[neilccbrown]

While running our test suite against the new TigerPython version I found two bugs triggered by some of our more awkward test cases that involved brackets around the item before the dot when doing code completion, and were then inside a function call.

Bug 1 — enclosing-call token range off-by-one (the originally reported bug)

AI description: Completer.getNameFilter's tokenRange lookup (Completer.scala:119) used
an inclusive upper bound, so when the caret sat right before a ) that
closes an enclosing call, that ) got swept into the range. That broke
the length/last-token checks that recognize the (expr).attr pattern, so
completion fell through to a full builtin dump. Fixed by excluding tokens starting at or after the caret from that range.

Original failing examples (### marks the completion position, right after the dot):

myString = "Hello from Strype"

# Controls -- all correctly show string members (e.g. "lower" present, no builtin dump):
wrap(myString.###)                  # no parens, wrapped -> works
("a".upper()).###                   # parens, NOT wrapped -> works
wrap("a".upper().###)               # wrapped, no outer parens -> works

# Broken -- all collapse to a full builtin-name dump instead of the correct members,
# even though the expression before the dot is always well-typed:
wrap((myString).###)                # parens + wrapped, var -> BROKEN
wrap(("a").###)                      # parens + wrapped, string literal -> BROKEN
wrap(("a".upper()).###)              # parens + wrapped, method-call result -> BROKEN

Bug 2 — numeric/boolean/None literals never tracked an end position

AI description: AstNode.Value / AstNode.BooleanValue (int/float/complex/bool/None
literals) never tracked an end position at all, unlike StringValue. So
they couldn't be registered by position in the completion machinery's node
map, and Scope.findName had no case for them either. This broke
(5).attr-style completion even at top level, unwrapped — independent
of the call-wrapping bug above. Fixed by giving both node types a real endPos (BooleanValue computes it
since True/False are fixed-width; Value gets it set from the source
token), and adding a fallback in Scope.findName that delegates to the
existing TypeAstWalker.getType for literal/expression kinds it didn't
special-case.

Original failing example for this (similar to above, but turned out to have a
distinct root cause):

wrap((5).###)                       # parens + wrapped, int literal -> BROKEN