Add export_module key to objects, even if they are overridden by the database

Currently, in Strongarm, variables are handled as 'faux-exportables', they live in the database and in code (if they have been exported by a feature) even if the database and the code are the same. This is done because it allows for a huge speed up because of built in variables caching in core.

However, it creates a problem as now Strongarm variables are in the database and in code. Ctools does handle this, however, when an object is in the database and in code, though ctools marks it as overridden, it does not provide the export_module key. This is the key that features uses to remove components that are already in another feature. Therefore, strongarm variables will often be exported to multiple features, causing conflicts and various badness.

So, I think we're at a strange place where ctools is working correctly, and strongarm has a bug, but the best and easiest fix is an addition to ctools. I propose to add the export_module to Overridden items when they are returned.

I will attach a patch to do this (as its a simple single line) in a reply. I will also open up an issue on Strongarm as that is where the real issue is, so people can track that there.

Thanks