remove infoplists_by_build_setting

[jerrymarino]

The API doesn't have any tangible benefit AFAIK but would love to learn otherwise. In Xcode there is no idiom of a per infoplist xcconfig so likely this just makes the rules more confusing to use.

This also fixes the issue raised in this change, which had to merge the keys of infoplist_by_build_setting : 66afc58

[jerrymarino]

cc @thiagohmcruz @luispadron if you have any objections to this please LMK - we can work together to fix any upstream code that depended on this key and provide a suggestion for people moving off of it.

[luispadron]

Agree we should get rid of it. After thanksgiving I'll look to update the plist processing to happen at analysis phase. From there we should be able to use the normal infoplists and select the plists we need without worrying about the macro reading the dictionaries.

After that, we can deprecate or remove the field. How does that sound to y'all?

[jerrymarino]

@luispadron cool - let's sync up at a later point in time on this. There is a couple obscure and newer feature in cocoapods that makes this harder to reason about.

I had to patch up some related code that required the previous behavior to noop. I think that aside your PR is more ideal / in the right direction.

Today the downside is you need the same exclusivity / configuration outcome of infoplists_by_build_setting and xcconfig_by_build_setting

[jerrymarino]

After digging into this a bit more, we can re-work some code to add better support this API. I had moved the xcconfig mapping to configuration time here: #618