main forces Python3_EXECUTABLE to the bundled *embed* interpreter (for the
in-app Python plugin runtime). ConfigCodegen.cmake used that same interpreter to
regenerate the config sources at build time, but the embed Python has no protoc
/ protobuf / pyyaml (and for cross-compiled targets isn't even the host arch),
so ninja's "Re-generating config C++ from changed .proto files" step failed with
"protoc not found" on every platform — even though the workflow's dedicated
codegen step had already generated the files.
Probe whether the interpreter can actually run the codegen (protobuf importable
AND a protoc available, standalone or via grpc_tools). Only wire up the
auto-regenerating custom command when it can; otherwise use the already-generated
files as-is (with a no-op codegen_config target) and only error if they are
missing. Adds ORCA_CODEGEN_PYTHON to let a build point at a tools-capable
interpreter independent of the embed one.
Generated files remain gitignored; the CI "Install codegen tools and generate
config sources" step still produces them before the build.
