Support custom entrypoints in public Windows API

[cbracken]

This adds a dart_entrypoint field to FlutterDesktopEngineProperties in
the public C Windows API, which mirrors that in the embedder API.

When a null or empty entrypoint is specified, a default entrypoint of
'main' is assumed. Otherwise, the app is launched at the top-level
function specified, which must be annotated with
@pragma('vm:entry-point') in the Dart source.

This change is backward-compatible for existing users of the Windows C API
and the C++ client wrapper API. To avoid breaking backward compatibility,
this patch preserves the entry_point parameter to FlutterDesktopEngineRun
in the public Windows C API as well as in the FlutterEngine::Run method
in the C++ client wrapper API. The entrypoint can be specified in either
the engine properties struct or via the parameter, but if conflicting
non-empty values are specified, the engine launch will intentionally fail
with an error message.

This change has no effect on existing Flutter Windows desktop apps and no
migration is required, because our app templates never specify a custom
entrypoint, nor was the option to specify one via the old method
particularly feasible, because the FlutterViewController class constructor
immediately invokes FlutterViewControllerCreate which
immediately launches the engine passed to it with a null entrypoint
argument, so long as the engine is not already running. However, running the
engine without a view controller previously resulted in errors due to failure to
create a rendering surface.

This is a followup patch to #35273
which added support for running Dart fixture tests with a live Windows
embedder engine.

Fixes: flutter/flutter#93537
Related: flutter/flutter#87299

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cbracken]

I'd be particularly interested in @knopp's review here as the author of an alternative embedder.

There are ways we could do this and fully preserve backward compatibility, though it likely involves coming up with some relatively unfortunate function names (particularly the no-entrypoint variant of FlutterDesktopEngineRun)

[loic-sharma]

Changes look good to me, but I'm conflicted on the breaking change.

[loic-sharma]

Talked offline, breaking changes shouldn't affect the vast majority of apps. We think the impact is acceptable.

LGTM

[cbracken]

Alright -- did some refactoring to avoid breaking backward-compatibility for windows embedder wrappers. Thanks for pushing back on this; the resulting patch I think gets us to a place where flutter/flutter#93537 is fixed and we have the fixture testing I wanted, plus preserves backward compatibility.

We can deal with the more contentious issue of how we deprecate the entrypoint parameter on FlutterDesktopEngineRun in the C API and FlutterEngine::Run` in the C++ client wrapper separately. I've filed flutter/flutter#109285 to track that.

[loic-sharma]

Suggested change

	// If sprecified, entry_point must be the name of a top-level function from the
	// If specified, entry_point must be the name of a top-level function from the

[loic-sharma]

Re-LGTM. Looks great! 🎉