fix(migration): ensure GenericObject type dropdowns are migrated

[MyvTsv]

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes #43878
• Here is a brief description of what this PR does
  The dropdown menus from an old GenericObject asset were not migrated correctly and caused a Twig error when the Fields block was displayed

Screenshots (if appropriate):

Old GenericObject type dropdown fields:

[Rom1-B]

Please fix CI

[stonebuzz]

Could you please have the cutsomer validatation ?

[stonebuzz]

Suggested change

	if ($DB->tableExists('glpi_plugin_genericobject_types')) {
	// Update old genericobject_itemtype dropdown fields to customasset_itemtype dropdown fields
	$has_genericobject_fields = $DB->tableExists('glpi_plugin_genericobject_types')
	&& $DB->request([
	'COUNT' => 'id',
	'FROM' => self::getTable(),
	'WHERE' => ['type' => ['LIKE', 'dropdown-PluginGenericobject%']],
	])->current()['COUNT(id)'] > 0;
	if ($has_genericobject_fields) {

getGenericObjectTypes() is called whenever glpi_plugin_genericobject_types exists, without first confirming that any fields actually reference GenericObject types. In container.class.php (line 162), the equivalent call is guarded by count($data) > 0, where $data queries for containers that contain a PluginGenericobject itemtype. If the table exists but GenericObject is uninstalled or at a version < 3.0.0, getGenericObjectTypes() throws RuntimeException (line 211-215 of migration.class.php). This exception is unhandled and will abort installBaseData() entirely, breaking the Fields plugin migration for any instance that has the leftover table but an outdated or absent GenericObject plugin.