context.destination.service.resource should include the logical database name for SQL Databases

According to https://github.com/elastic/apm/blob/master/specs/agents/tracing-instrumentation-db.md#sql-databases `context.destination.service.resource` should by set to the database vendor/span subtype. In my opinion this is not granular enough. A single application might talk to different databases (of the same vendor), which may be on same or on different hosts/servers. In a distributed architecture different applications might talk to the same or different databases (of the same vendor), which may be on same or on different hosts/server. In both cases `context.destination.service.resource` will be the same (e.g. `postgresql ` for PotsgreSQL). Thus Kibana cannot distinguish between the different databases in the service map/dependencies. It is also not possible to see the latency, throughput and error rate for each database individually, because these metrics are aggregated based on `context.destination.service.resource`.

I propose to add the logical database name to `context.destination.service.resource` for vendors that support the notion of a logical database name. The auto inference algorithm described in https://github.com/elastic/apm/blob/master/specs/agents/tracing-spans-destination.md#contextdestinationserviceresource does something similar.

E.g. for PostgreSQL `context.destination.service.resource` would be `postgresql/mydb` if one connects to a database called mydb (`CREATE DATABASE mydb`).

What do you think, does this make sense? How should the logical database name determined for the different database vendors? Should there be config option to switch between both behaviors?