Make flag instances configuration, not stored in the database.

[Graham-72]

In starting work on a Forum for the Backdrop project we notice that settings of Flags cannot be moved readily to another site ( part of backdrop-ops/forum.backdropcms.org#7).

More porting work on Flag is needed to achieve this. @jromine are you able to do this or shall I have a look?

[jromine]

You are welcome to proceed.

[Graham-72]

Thanks. I will have a look at it soon.

[quicksketch]

I made a PR at #38 that undertakes this rather large migration effort.

• Dropped the "flag" and "flag_types" tables - these are now stored in config files.
• Converted "fid" column to "flag_name" in "flag_counts", "flagging", and "flag_actions" tables.
• Removed use of $fid as a parameter in all functions. Fortunately loading by $flag_name was already the preferred and default way of loading flags in most of the code base.
• I deleted the entire FlaggingController class because it no longer needs special handling to convert fid to name on the entity bundles. Flaggings can now use EntityDatabaseStorageController directly.
• Deleted flag_flag::factory_by_row(), since we now only use flag_flag::factory_by_array()

I tested and confirmed that all tests are now passing (though they weren't actually passing even before). And I ran the update hooks on my local site with success converting the database-flags to config-flags.

This is a huge change in the way Flag module works and would probably be a good idea to increment the major version number to indicate the scope of it. But I sort of think we should bump up to 1.x-3.x anyway to match the FLAG_API_VERSION in the code and correspond to the matching Drupal version.

[quicksketch]

Thank you @herbdool for reviewing and merging this change!