PartTree Delete queries cause nested Spanner transaction when using @Transactional

**Describe the bug**
I am not sure if this is expected behaviour, but Spanner delete operations raise exception within methods annotated with `@Transactional`.

**Sample**
```
@Transactional
public void handle(String ownerId, List newEntities) {

itemRepository.deleteByOwnerId(ownerId);

itemRepository.saveAll(newEntities);
}
```

On entering this method a transaction is created: `Creating new transaction with name [com.xxx.xxx.UpdateItem.handle]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT`

But executing `deleteByOwnerId` then triggers an `exception:java.lang.IllegalStateException: There is already declarative transaction open`.

I know Spanner does not allow nested transactions, and [the docs](https://github.com/GoogleCloudPlatform/spring-cloud-gcp/blob/8a26f8c866afdf879dc416460822fa6b94ff2809/docs/src/main/asciidoc/spanner.adoc#query-methods) state "The delete operation happens in a single transaction". But I wonder if this expected behaviour when using @Transactional? Should the delete run inside the existing transaction?

**Workaround**
The workaround is to first read the entities to delete and then call `itemRepository.deleteAll(entitiesToDelete)`

NB: This is using version 1.2 of spring-cloud-gcp

Start with the PartTree delete path invoked by itemRepository.deleteByOwnerId inside the @Transactional handler and reproduce the reported nested-transaction exception. Compare it with the deleteAll(entitiesToDelete) workaround and the query-method documentation linked in the issue. Done means the expected transaction behavior is established and the delete path either works within the existing transaction or is clearly documented.

Written by the indexing model from the issue text.