Explain the internal working of StreamPark Core's RuntimeContext abstraction?

RuntimeContext is the piece of StreamPark Core that turns "a Flink program" into "a StreamPark job" by standardizing how the program learns about its own environment and configuration at startup.

When a job built with StreamPark Core starts, RuntimeContext is responsible for parsing the job's configuration (whether plain properties, YAML, or HOCON) and constructing a ready-to-use StreamExecutionEnvironment (or the Table/SQL equivalent) already wired with the settings that configuration implies — parallelism, checkpointing behavior, restart strategy, and so on — instead of leaving each job to repeat that wiring by hand.

It also acts as the handle developers reach for to pull in StreamPark's out-of-the-box connectors: rather than instantiating a Kafka source with its full set of constructor arguments, code written against RuntimeContext calls a shorter, connector-aware method that already knows how to translate the job's declared configuration into the underlying Flink connector's setup.

Because this context is constructed the same way for every job that uses StreamPark Core, two developers' jobs end up structurally consistent — same environment-setup pattern, same configuration source of truth — even if their business logic is completely different, which is exactly the "standardizes project configuration" promise StreamPark makes.