Delete module with managed resources and operator resources

[pbochynski]

Description
Users should be aware of existing resources coming from the modules when they choose to delete one of them. If there is at least one resource user should be given a choice on how to proceed:

1. cancel the deletion (nothing happens)
2. delete all managed resources first and once the list is empty then delete the module

When the module is managed (entry exists in the default Kyma CR) the deletion should only remove that entry from Kyma CR. For not managed modules deletion should actively remove all module operator resources.

Reasons
Currently, the module deletion process can hang and users have to figure out how to unblock it themselves. The module operators wait until all dependent managed resources are deleted. Users have to find all of these resources and delete them one by one.
Another problem is that users are not aware of the consequences of the module deletion and can trigger deletion even if the module is in use (a lot of resources exist).

Acceptance Criteria

• A list about affected resources is displayed after clicking the trash icon or Delete on the module
• List in the warning modal contains information about the number of the existing affected resources (example: If user has 10 VirtualServices and wants to remove istio module, then in warning there should be info about this VS)
• User can abort deleting by clicking Cancel
• User can click force delete to remove all affected resources and then remove the module - Force delete kyma module #2613

Attachments
Epic: #3447
See the deletion scenario in this issue: kyma-project/kyma#18450

[mrCherry97]

Will be planned after kyma-project/lifecycle-manager#1472
They will prepare the testing environment for us, and we will start working on this topic.