Translate field properties used in entity_get_property_info()

I can confirm this problem still exists. For me the proposed solution works good, but we need further feedback!

due to testbot change this patch needs another test.

reroll of original patch 2 , same patch as #2 but new name.

Fixed in dev 7.x-1.x , let this simmer for a while in dev.

After updating to the latest dev I've got a recursion loop that's caused by this adjustment.
Scenario:
Cold cache.

1. Menu Rebuild - invokes hook_menu
2. commerce_flat_rate_menu() is invoked.
3. This usescommerce_flat_rate_commerce_shipping_service_info(), which calls i18n_object('commerce_flat_rate', $service)->translate($language->language);
4. Due to cold cach this leads to trigger i18n_object_info() which builds the cache.
5. So i18n_object_info() invokes $info = module_invoke_all('i18n_object_info');
6. The entity module implements the hook: entity_i18n_object_info()
7. This tiggers RulesI18nStringController::hook_object_info() which bases on EntityDefaultI18nStringController
8. So EntityDefaultI18nStringController::translatableProperties() is called.
9. This calls entity_get_all_property_info() which bases on entity_get_property_info()
10. So the hook hook_entity_property_info is triggered.
11. The entity module implements entity_entity_property_info() which calls entity_metadata_field_entity_property_info()
12. Here the new callback i18n_field_entity_property_callback() is called.
13. The function uses i18n_field_translate_property() this relies on i18n_string_object_translate()
14. Unfortunately i18n_string_object_translate() relies on i18n_object() aaand we're just rebuilding it's cache and without cache it's rebuilding the cache... means restart at 4.

I'm not yet sure how to proceed yet as I don't spot an obvious issue in the implementations - just a an unfortunate combination of dependencies. However, given the recent change introduced this issue I'm afraid that we've to solve it too.

@das-peter thanks for the thorough analysis, one question, so does backing off commit at #6 avoid the recursion loop?

@joseph.olstad Took me a moment but I think I was able to come up with some sort of solution ;) If the i18n_object_info cache isn't present we skip the processing but rebuild entity_get_property_info in our implementation of hook_i18n_object_info_alter(). By using i18n_field_module_implements_alter() we ensure our implementation of hook_i18n_object_info_alter() is the last that runs. This means we should have the full data for i18n_object_info - even if not, at least we wont end up causing a endless recursion.
The attached patch also adds a watchdog logging in case i18n_object_info still isn't available . might help us to identify some other edge cases.
The solution will have a small window in which untranslated property info are cached / used - but this approach was the best I could think of.

@das-peter figured we should commit this immediately into dev

stalling a release until dev gets more bake time.

Whao great, thank you very much!

@joseph.olstad Thanks for committing I didn't that right away since I wanted another pair of eyes checking out what I came up with ;) But I agree with the fast commit!
Now let's see if someone hit's the new watchdog message ;)