fix a create reporting the identifier of the request body

[cportele]

For a feature type whose identifier the database assigns on insert, a create reported the value of the id column in the decoded request body instead of the identifier the insert returned: the Location header of the response named a feature that does not exist, and the per-role column overrides of a transaction updated no row, because they are keyed on the reported identifier.

The value of the id column in a written feature is the identifier of the feature only where the client assigns it, for example a gml:id decoded into an objid column, where the surrogate primary key is not the identifier. Where the database generates the identifier, a value in the request body is not inserted at all, so the identifier is the one the insert returns.

SqlQueryMapping.hasGeneratedId is the rule that decides this, lifted out of FeatureProviderSql.hasGeneratedId, which used it for the collection metadata already, and applied where the mutation session determines the identifier of a written feature.

CreatedFeatureIdSpec locks which id a write reports, for all four variants of the documentation: a generated id, a client-assigned id in another column, a primary key with {generated=false}, and an id the caller states. The rows and the insert statements are stubbed, so the rule is exercised without the stream that drains the request body; the entry point that the spec drives derives the id from the mapping, which the two callers used to do with duplicated code.

Note that this is an edge case where the URIs are inconsistent with the id properties.