Play nice with install profiles

UUID seems to explode pretty amazingly as part of an install profile, at least from my limited experience this seems to be true. After a lot of hunting I can tell there's definitely a race condition in terms of entity info being appropriately altered along with subsequent schema (cached and actual table) being updated as well. This can result in scenarios where the entity is present and UUID _THINKS_ it's been updated properly but the table is still missing the field.

In order to solve this I made a handful of changes, most importantly that uuid_uuid_sync() creates the fields if they're still missing.

Secondly, the entire reliance on uuid_get_core_entity_info() instead of entity_get_info() with some key checks is very bizarre. We should transition away from that function entirely in the long term and put together a hook that does this work and the leverage it at all the various stages (entity/schema/table) instead of rewriting it each time and making modules that depend on this one (commerce_uuid) implement the exact same logic again for their set of entities. It makes little sense. In addition to this, I removed the "if (module_exists())" checks in uuid_get_core_entity_info(). Relying on an isset() check in the entity_info_alter() is much more reliable because in some situations (like during site install) you might have the entity info, but module_exists() returns false.

This patch should be a pretty basic solution and we can hash out a more streamlined solution long term. I'm categorizing this as major since it actively prevents install profiles from utilizing this module.

Eclipse