Update libstarlark to latest bazel branch

[mahmoudimus]

Description of changes in release / Impact of release:

Import latest changes for Starlark from bazel upstream: bazelbuild/bazel@50c8f32

Documentation

• Eliminate raw field from the Lexer. This is a micro-optimization to avoid
  eagerly allocating a String every time we process a token, when only IntLiteral
  and FloatLiteral care about the raw text. 227da61a0a522e
• Intern identifier and keyword Strings in the lexer. This makes it so that the
  lexer returns a (weakly) canonical String instance for all occurrences of a
  given identifier or keyword token. This change was prompted by ilist@'s
  observation that there are many duplicate Strings that appear in profiling,
  consisting of common Starlark identifiers such as "name" and "ctx". Benchmark
  results: Interning identifiers+keywords was observed to save 3-4% on
  a bazel query deps(...) invocation of bazel itself, and almost 1% on a much larger
  target. Static strong interning was a bit better than static weak interning,
  which in turn was a bit better than non-static (strong) interning. We went with
  static weak since static strong would constitute a memory leak for long-running
  Bazel servers; this follows precedent elsewhere in Bazel. We considered
  interning bufferSlice() as well, which would intercept all conversions of the
  lexer's source text to String objects, but this showed no noticeable improvement
  and actually regressed RAM usage in some cases. The parser already interns
  string literals; that is unaffected by this CL. Note that we use Guava
  interners, not BlazeInterners, because this is Starlark interpreter code that
  must not depend on bazelisms. 9bf5a14850685
• Catch an unchecked exception which may be thrown by Strings.repeat(). To
  provide a nicer error message for the user. Otherwise, we'd get an
  UncheckedEvalException without a Starlark stack trace. 1bd78126b14f
• Catch EvalException in toIterable calls, ensuring that error line numbers are
  set correctly.592c38445e42
• Include the Starlark stack trace as part of the crash's stack trace for all
  unhandled throwables originating in Starlark evaluation. In keeping with
  tradition of not wrapping Error in AbstractParallelEvaluator, different
  exception types are used for RuntimeException and Error. Additionally embed
  a context supplier in StarlarkThread. 86b32a64f596
• We want to restrict the type to a Sequence in Java (to avoid an unsafe cast)
  and to document it as a sequence of unspecified type in Starlark API
  docs (unfortunately, ParamType annotations currently don't allow us to express a
  Sequence containing 2 different allowed types possibly intermixed). 8a43e0cb973ab9
• Fix toolchains to support type lookup. b120d4febc571
• Create a new interface to allow Starlark objects to get a thread when getIndex
  is called. 68effbecba59

Risks of this release

None

Is this a breaking change?

• Yes
• No

Is there a way to disable the change?

• Use previous release
• Use a feature flag
• No