[BUG] BTP Provider is not considering resourceUsages when deleting resources

[dholeshu]

Describe the bug
Hey,
we are currently facing the following scenario:

• MCP running in BTP Subaccount A
• we have one helm chart to install all the CRs to do the following:
• using the opensource BTP Provider to import an existing Subaccount B (via externalname + managementPolicy: Observe + deletionPolicy: Orphan)
• provision resources into the imported Subaccount B, like Entitlements, KymaEnvironment and others
• when uninstalling the helm chart, the subaccount B “import” CR is gone immediately, but the other CRs are switching their states to READY false / SYNCED false but not actually getting removed from the cluster and only partially removed in BTP (i guess it depends in which order API calls are going through before the subaccount is no longer available in-cluster)
• the remaining resources show:

connect failed: cannot track ResourceUsage:
  [subaccount.account.btp.sap.crossplane.io](http://subaccount.account.btp.sap.crossplane.io/) "subaccount-b" not found

• also the ResourceUsage CRs remain in the cluster

Tested with Provider Version
v1.0.2

To Reproduce
Steps to reproduce the behavior:

1. Create a helm chart that does the following:

• Import an existing subaccount with externalname + managementPolicy: Observe (deletionPolicy should be redundant in that case)
• Provision some resources in the imported subaccount like entitlements or environments

2. Install the helm chart to MCP running a configured BTP Provider
3. Wait for all resources to be synced and ready
4. Delete the helm chart and check cluster CRs and BTP resources

Expected behavior
The provider should take care to respect the ResourceUsages when deleting / cleaning up resources that have a dependency, even if they are only imported.

Other
There was a discussion in slack already and the proposal was:

We can potentially rethink the error handling of resourceUsage in general. 

Blocking those other resources here might not really do any good in a case like that. 

At least in this particular case the controllers should have everything they required (in this case the subaccount GUID) cached to fulfill their technical requirements. 

So maybe we could silently except this missing references here. I am not sure about all potential implications at this point though.
```