[RFC] Config plugins

[EvanBacon]

Why

When syncing projects there are going to be certain cases that cannot be abstracted completely, for these cases we'll need a way to pipe raw data through an interface that plugins can modify.

For instance, say a plugin needed to add a new activity to the AndroidManifest.xml, in this case it can use the new config to modify the JSON directly.

We'd still encourage that most props use the expo abstracted fields like android.metadata or ios.infoPlist.

How

Created a new config namespace that doesn't get serialized at evaluation:

module.exports = {
  expo: { /* Expo config... */ },
  // New config
  pack: { 
    android: { 
      manifest(props) {
        // props.data === { json version of AndroidManifest.xml }
        // JSON gets modified and returned for expo to continue bundling.
        return props;
      }
    }
  }
}

Internally we extend this system for our built in third-party plugins like Facebook, Branch, Google Maps, etc. In user's app.config.js, they could utilize the same composition pattern:

export default compose(
    [
      withFacebook,
      [withBranch, { apiKey: '...' }],
    ],
    { expo: {}, pack: {} }
  );

• The config will need a method to "compile" the plugins.
• Common plugin actions should be exported.

Considerations

• Obviously pack is just a placeholder namespace.
• Maybe we should move more build related fields over to pack -- but aren't they basically all build related fields.
• Possibly better to support android.manifest() {} that only gets used for building and stripped from the public manifest.
• Perhaps data should all be piped through the same singular method and delegated in the plugin itself { expo: {}, pack({ files }) { return {files} } }

Test Plan

• TBD

[EvanBacon]

Closing in favor of #2849