Ignore null/undefined config objects and return a useful error about the file with the problem

[evantahler]

1. If there are null or undefined config objects, we now return an error with the filename that has the problem (rather than mysteriously crashing)
2. If there's a problem saving the Sample Record, don't write null to the config file

This PR also changes config object writing (specifically for records, but it may apply in the future to other config types). This allows for merging config objects that share a destination filepath.

What this allows us to do is break out Record config files on a per-model basis

Before:

config/development/records.json

After:

config/development/customers/records.json
config/development/accounts/records.json

Thanks to @rwfeather!

Checklists

Development

• Application changes have been tested appropriately

Impact

• Code follows company security practices and guidelines
• Security impact of change has been considered
• Performance impact of change has been considered
• Possible migration needs considered (model migrations, config migrations, etc.)

Please explain any security, performance, migration, or other impacts if relevant:

Code review

• Pull request has a descriptive title and context useful to a reviewer. Screenshots or screencasts are attached where applicable.
• Relevant tags have been added to the PR (bug, enhancement, internal, etc.)

[pedroslopez]

Few questions mainly to understand what was causing the null objects and to make sure it was being addressed since, while I see errors being handled on the config loader, the generation of record config objects seems like it hasn't changed.

If my assumptions are correct, looks good!