[ios] Consider moving FlutterBinaryMessenger/FlutterTextureRegistry implementation out of FlutterEngine

### Use case

FlutterEngine itself does not publicly conform to FlutterBinaryMessenger and FlutterTextureRegistry. Instead, it exposes properties of these protocols:

```
@property(nonatomic, readonly) NSObject* binaryMessenger;
@property(nonatomic, readonly) NSObject* textureRegistry;
```

Internally, FlutterEngine.mm adopts these protocols, and these getters simply return itself, or rather, a weak pointer container of itself (e.g. FlutterBinaryMessengerRelay).

I like this composition-style public API setup, because it allows us to freely change implementation and move the logic out of FlutterEngine (single responsibility principle).

### Proposal

Move FlutterBinaryMessenger/FlutterTextureRegistry implementation out of FlutterEngine.

Backward compatibility note: `FlutterEngine` used to publicly conform to these protocols, but later we had a breaking change, which removed this public conformance. It's possible that there are still ObjC code out there relying on FlutterEngine having those methods. We should make sure it still works, and ideally add a deprecation warning (we should have add the warning when we introduced the breaking change, but better late than never). See discussion https://github.com/flutter/flutter/issues/172718

Start in FlutterEngine.mm and inspect the FlutterBinaryMessengerRelay and FlutterEngine implementations of FlutterBinaryMessenger and FlutterTextureRegistry. Review the compatibility discussion in issue 172718, then determine how the implementations can move while preserving existing Objective-C method behavior and adding the proposed deprecation warning.

Written by the indexing model from the issue text.