Upgrade procedure should check for custom fields name before starting the upgrade

I have upgraded two CiviCRM sites for now, and I have run in the following bug:

• some civicrm_custom_field entries had a name which was NULL (they were civicrm 1.8). I had to fix those by manually editing the database (does it have an impact?). However, CiviCRM only warned me about the error at step 5 of the upgrade. It was impossible to go back, and I had to restart the upgrade from an SQL dump. It would be better if the check was done before the first step of the upgrade.

• some civicrm_custom_field entries had a name which is a reserved SQL word. In my two tests, one had a field called "Group", the other had a field called "Database". They cause an SQL error in step 5. This too should be checked, so that admins can fix it before the upgrade. (I guess it is not a very common error, so having a more complex handling of the error is not really worth it.)

Thanks,
Mathieu (bgm on #civicrm)

P.S. While I am mentioning upgrade issues, I also had a problem that some tables were using the collation "utf8_general_ci" instead of "utf8_unicode_ci". This is probably a problem with my sql dump or of the mysql default configuration of my host. I fixed it by adding the collation to each "create table" in my dump. I just wanted to mention it in case other people run into it. I'm not sure what's the impact of changing that, but as far as I understand, the difference is mostly that utf8_general_ci does wrong sorting for non-ascii letters. However, the database I was upgrading is in English, so I could not really see the impact.