Fix EZP-22808: BinaryFile fields loose value when updated via API

This PR resolves issue https://jira.ez.no/browse/EZP-22808

This fixes two closely related bugs.

1. When creating a new Content draft for a Content containing binary fields (BinaryFile and Media), fields in a draft would lose value.  This happened because of a bug in external storage, where standard data payload was checked instead of external data payload.

2. When updating Content and providing values for binary FieldTypes (BinaryFile and Media) were given from loaded Content, the update would result in exception. The same would happen if updating without providing value for binary field, as in this case field value is loaded from the draft in order to be validated. This happened because binary field types were not capable of handling input value that was loaded from existing Content.

The problem is fixed by introducing `inputUri` property on binary field value, used to provide path to a file when using the value as input. Previously this was handled by `id` property, which in storing changed to unique id. Such usage of `id` property is now deprecated in a BC way, and if `id` is used in input to provide field a URI to a file, it will be assumed it contains unique id of a stored file in case it does not point to an existing file.

The logic here is that we assume trust in user input.

FieldType API integration tests are updated with a case where Content is updated without providing a value for a field. This also exposed the issue reported in https://jira.ez.no/browse/EZP-22870, which is therefore fixed here.