Upgrade concerns for fields from 7.x -> 8.x that utilize non-sql storage.

This issue is stemming from #569434: Remove taxonomy term description field; provide description field for forum taxonomy whereby the current patch creates a field for taxonomy using field_sql_storage as the storage mechanism. Looking through drupal core, this kind of check happens surprisingly often (or in the case of something like forum from 7.x update_7003, explicitly stating an upgrade cannot be performed on a field because it does not use field_sql_storage). My concern with creating fields in this way will be that, while using non-sql storage like MongoDB might have been less common when 7.x was released, modules like mongodb, efq_views, etc are certainly driving more and more sites to utilize non-sql storage. The D7 mongodb module also has a migration module to convert fields from sql storage to mongodb (thus making the barrier to enter much easier).

But if we are upgrading a site, anything that is using mongodb at that point is going to require non-trivial work since these fields are being created via sql storage (functions like _update_7000_field_create_field explicity store only using field_sql_storage). I talked about this with @tim.plunkett briefly and it seems like one alternative we could pursue is to actually resave the entity with the updated data in the update batch scripts when new fields are created / have their schema modified. Its a *much* slower process but it should hopefully guarantee that field creation respects the default storage format of the site. I'm refraining from classifying this as a bug report at the moment.

I'll see how far I can get with this idea but it would be great to figure out a plan on how to handle this issue.