Improve checking of entity type based on hook.

I agree that the current approach is crap, but I am doubting that anything that requires a module to add something in it's theme registry and relying on magic keys to get the entity object is also not the optimal solution. I'm working on something that may work a bit more reliably.

So if we were to try and get away from a theme registry / preprocess approach for detection, what else do we have?

Well we have the hook_field_attach_*() hooks, including hook_field_attach_preprocess_alter() which sounds like it could be useful, but those hooks are only available to entities that are fieldable, which may leave some entities that are viewable but not fieldable out.

Next up is hook_entity_view() and hook_entity_view_alter(). Using hook_entity_view_alter() is out since at that point we've lost the easy context/variable of the entity object and we're back to the same problem. But hook_entity_view() is very interesting. We're provided with specific variables for entity type, entity, view mode, and language code, all the things we need later. If we can store this information in the render API, and then detect this information later in the preprocess, this is pretty much a fool-proof method I think. As for reliability across all entity types, as far as I know, all entity types should to implement both of these hooks if they are viewable (and better yet in D8 it actually is enforced). The one entity type that violated this assumption was Fieldable Panels Panes, and I committed a fix to add the hook invocation: #1900528: PanelsPaneController::view() invokes hook_entity_view_alter() but doesn't invoke hook_entity_view().

Patch incoming.

Patch attached for review that implements #4. The only unexpected thing I found is that when rendering a user account via theme_user_profile, core also somehow puts the user render API array into a block, which then also runs preprocess and unwantingly detects our variables. I accounted for this by checking to make sure that the $hook variable actually matched the #theme function set in the entity's view callback.

This really helps clean up the preprocess, and should really speed it up since we don't need to call entity_get_info() every time. What I didn't also express about the solution in #2 is that this also requires every entity module to add our preprocess function into their theme registry information as well. This alternate way, doesn't require anything of them at all, aside from implementing the required APIs that they normally would have to.

I passed in langcode by reference, because I was thinking what if it changed somehow, but then I realized that is very silly and it should never happen, so it should be removed.

I wonder if checking for the render element would actually solve the weird issue I had with user entities and blocks.

Just checked, both $hook = 'user_profile' and $hook = 'block' use render element of 'element'. I think my concern with checking the actual render element on the preprocess means we have to do it first, which means that it has to happen for every single invocation of the preprocess function. I think we can just be ok with relying on that entity types always use the standard render element. If we encounter problems down the road we can deal with them then.

Patch includes tests now as well.

Helps to include the new testing module.

Added test condition for #1831766: Theme hook suggestion for {$entity_type}__{$bundle}__{$view_mode} is added before {$entity_type}__{$bundle} .

Patch in #13 also prevents template suggestions with entity bundles from being added to entities that have no bundles.

Confirmed that #14 fails if 1831766 was reverted, so committed to 7.x-1.x! http://drupalcode.org/project/entity_view_mode.git/commit/6ec3774

Thanks for your help in getting this resolved bangpound!