Refactor internals to NOT rely on RuntimeDataStore

[MateuszKubuszok]

Currently in a lot of of places we use ctx.runtimeDataStore(idx) directly, while TransformerConfiguration's overrides store only idx.

We could move this extraction to TransformerOverrides, so that the code would NOT hardcode how we are storing/parsing runtime information.

• TransformerOverrides would store overrideExpr: Expr[Any] instead of index: Int
• this overrideExpr could be computed in TransformerConfiguration.readTransformerConfiguration
• every usage of ctx.runtimeDataStore(idx) could be replaced with overrideExpr

This way, in the future we could:

• provide an alternative API without any runtime overhead:

  // no overhead for building Vector and extracting values from it
  foo.transform[Bar](
    Const(_.a.b.c, value),
    Computed(_.d.e.f, foo => anotherValue)
  )

  (By alternative I am thinking a separate module or even a separate library - to avoid confusion from one-in-one API - import dsl.* - and API split into components - auto.* + inlined.* + syntax.* - and then yet another API for inlined expressions without fluent API overhead like Ducktape's.)

• open up possibilities to reuse macros to provide e.g. lens-like functionality

  // already possible!
  (foo: Foo).into[Foo].withFieldConst(_.bar.baz, value).transform
  
  // could be possible to implement
  foo.updateInline(
    Const(_.bar.baz, value)
  )

  (If we'd compare to e.g. Quicklens, and if we only consider .setTo, Chimney would only be missing foo.modify(_.list.at(idx)).setTo(item). If we could chain updates without any overhead, then we could get better performance than foo.modify(...).setTo(...).modify(...).setTo(...)),

• make it easier to reuse Chimney derivation engine in other libraries (from what we can see Teleproto already attempts such thing in Try turning teleproto into a wrapper around chimney moia-oss/teleproto#321)