Endless looping on Config::castValue() for undefined config data type

The test currently works because an exception is being thrown by Symfony's YAMP dumper \Symfony\Component\Yaml\Exception\DumpException. I think it is an improvement to move the error up to the Config class and make it independent of the Config storage layer.

But I think we need to ensure that the exception thrown is consistent. So we have to decide how to do this. Config data is set through two methods - we could throw an exception in the set() method if the value is an unsupported data type. But we have an issue with setData(). The current patch won't throw this exception for config that does not have schema.

So I think we need to add a catch in FileStorage::encode() for the DumpException and rethrow a UnsupportedConfigDataTypeException. Actually looking at the name of the exception I think iUnsupportedDataTypeConfigException is better since this extends ConfigException. In order to test this we need to try saving to a config file that has no schema. The test should also assert that the config object has no schema just in case someone tries to implement one at a later date.

- Renames exception
- Catches DumpException in FileStorage::write (Not in encode, so we can provide the config name).
- Added a new test for this, that has no config schema.
- Minor other changes.

It's going to be great to get helpful error messages from CMI +1

Nice change, committed pushed to 8.x, thanks!