As a developer, I want to be able to create a new Wikibase property in its entirety
`POST rest.php/wikibase/v0/entities/properties`
```
{
"property": {
"data_type": "string" (required)
"labels": {},
"descriptions": {},
"aliases": {},
"statements": {}
},
"comment": ...
"tags": [ ... ]
"bot": false
}
```
**Acceptance criteria**
- 201 response code on success, with JSON representation of the property created (same structure as GET ../property/P123 resource) and location header in the successful creation response
- Ignore HTTP conditional request headers
- Ignore id and type fields, and any unrecognized fields if provided in the request payload
- Error causes to be similar to PATCH properties
- ETag, last-modified and location (URI of the newly created item) as response headers.
- Handle user authentication/authorization like in `POST /entities/items/{item_id}`
- Client can provide additional edit metadata: mediawiki tags, edit summary text to append to the automated summary, and a bot edit flag, like in POST /entities/items/{item_id}
**Error cases to consider**
1. 400, value-too-long
2. 400, statement-group-property-id-mismatch
3. 400, referenced-resource-not-found
4. 400, invalid-value (invalid data type should be covered here)
5. 400, missing-field (missing data type should be covered here)
6. 400, invalid-key
7. 400, resource-too-large
8. 403, permission denied (incl. property specific `property-create` permission)
9. 422, data policy violation (property-label-duplicate and label-description-same-value)
10. 429, request limit reached
**Task breakdown**
* ~~add to OAS~~ (T377147)
* happy path (T377148)
* add `PropertyCreator` interface and implementation
* include revision ID and last modified date
* edit summary
* authorization
* add new method to `PermissionChecker::canCreateProperty( User $user ): bool` and implement it
* top-level field validation
* check top level field types
* check that the data_type field is present
* consider implementing this as a regular use case validator instead of creating a `RequestValidatingDeserializer`, because the `RequestValidatingDeserializer` would only be usable for this one use case
* field validation
* apply middlewares (the usual ones except the one for conditional requests), use `UpdateExceptionHandler` in the use case, and add the new route to RouteHandlersTest
* spec tests
* mark production ready, update changelog and OpenAPI interface version