Win32: Add lifecycle channel support

[moko256]

This PR adds flutter/lifecycle channel support for win32 and winuwp(removed), and enable apps to receive window focused/minimized event.
This PR adds StringMessageCodec to shell/platform/common.

This PR will support part of flutter/flutter#103637

No changes in flutter/tests.

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.

Example (main.dart, modified from WidgetsBindingObserver example in docs):
This app displays last event and print it to stdout.

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const AppLifecycleReactor(),
    );
  }
}

class AppLifecycleReactor extends StatefulWidget {
  const AppLifecycleReactor({Key? key}) : super(key: key);

  @override
  State<AppLifecycleReactor> createState() => _AppLifecycleReactorState();
}

class _AppLifecycleReactorState extends State<AppLifecycleReactor>
    with WidgetsBindingObserver {
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance!.addObserver(this);
  }

  @override
  void dispose() {
    WidgetsBinding.instance!.removeObserver(this);
    super.dispose();
  }

  AppLifecycleState? _notification;

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    print('Last notification: $state\n');
    setState(() {
      _notification = state;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text('Last notification: $_notification');
  }
}

[moko256]

I resolved the conflicts and this is ready for review.

[ollyde]

We need this desperately. Do we have a commit for MacOS as well?

[moko256]

@OllyDixon Sorry, this PR is for Windows only (and I don't have Mac now), but StringMessageCodec in this PR should help its implementation for MacOS and other platforms too.

[moko256]

@cbracken I ping softly (sorry if this was already triaged and is just low priority)

[flutter-dashboard]

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

[skia-gold]

Gold has detected about 27 new digest(s) on patchset 5.
View them at https://flutter-engine-gold.skia.org/cl/github/29288

[cbracken]

Cross-referencing flutter/flutter#65061 since it's related.

[Eldeloro1]

``

[moko256]

@cbracken @loic-sharma This is ready for review now. Please review this at your convenience.

[loic-sharma]

Is it possible to receive a WM_SETFOCUS or WM_KILLFOCUS message even after the window isn't visible? Would that scenario result in a pause event? If so, that seems undesirable.

[loic-sharma]

Would it be possible to add an integration test to the engine using flutter_windows_unittests.cc and its corresponding main.dart fixture? In theory you should be able to post Windows messages and check you receive the expected lifecycle message in Dart.

[gspencergoog]

This is a useful PR, and I'm aware that we very much need lifecycle event support, but I'm concerned that if we do this without a coherent strategy for all of the platforms that we'll end up with a fractured API for it that will require special handling for each platform on the framework side. Can we hold off on this just a little longer until we have a unified design?

[moko256]

@gspencergoog I agree with that, but I don't have much time to fix this now.
I'm sorry, but I'll close this for now.

[loic-sharma]

No worries! Your work will help inform the unified design, thank you for taking a first stab at this problem