Update target config after init macros

[kLabz]

One example that does go wrong is setting -D js-unflatten during init macros: generation will follow this define, but reserved names will be computed with js flatten.

[kLabz]

@Simn can you think of things that could potentially go wrong when doing that, so that I can check if it's ok?

[kLabz]

Also could be a candidate for a potential 4.3.x release.

[Simn]

I think this is fine, but I'm unsure if there really should be 3 calls to update_platform_config. Could you check if we still need the one in compiler.ml with this change? There's a comment there saying "make sure to adapt all flags changes defined after platform" but I don't really know what that means, so maybe some clarification would be good here.

[kLabz]

It doesn't seem like we have tests for this, so it's a bit hard to tell.

However, we do expose platform config to init macros through Compiler.getConfiguration(), so this would likely have an impact, meaning that as far as macros are concerned, all of these calls are necessary to provide correct data?

Also, what I saw when looking at this is that after_target_init callback is being called after the update_platform_config call you mentioned, meaning any changes in init macros wouldn't be considered there; maybe that's ok? (though projects that have defines added during init macros will have a different signature in there) Anyway, that isn't related to this PR.