Bug in /api/admin/datasetfield/load - possible to overwrite a field with a field with the same name IN A NEW BLOCK

Our datasetfieldtype setup relies on the fields being unique across all the metadatablocks installed. That's how the API knows if it's a new field, or a field that needs to be updated when you reimport a block from a .tsv file, etc.
There appears to be a problem with that arrangement - it is possible to add a NEW block with a field that has the name of an existing field in another block; and it will silently overwrite an existing field, and reattach it to the new block. Thus changing the nature of any existing field values in the database.

We probably want the api to reject to load a new block with a “sorry, you already have an installed block xyz that has the field type with the name abc”.

Also, we could add something to our docs on how to create new blocks. To encourage people to use less generic names for the fields in their custom blocks; along the lines of myBlockSpecificRepository instead of simply Repository.

Edit: there was a suggestion to provide a flag that would force the API to move an existing field from an existing block and into a new one (i.e., the current behavior); in case an installation admin actually has reasons to want to do this.

Start at the /api/admin/datasetfield/load entry point and reproduce importing a new block from a .tsv file when another block already has the same field name. Trace how the existing field is selected and reassigned, then verify that conflicting loads are rejected without changing the existing field. Update the documentation on creating blocks if that remains in scope.