Avoid deleteing app-packages from database

Currently a package can be deleted from the database entirely from CLI or dashboard. This leads to some serious issues. User can deploy an environment with applications defined in the package and then delete the package. After that user would be unable to delete the environment and unable to run any actions (if any registered by package) against deployed application.
One can later re-upload the package, but this also leads to a possible issue, that classes could have changed in the re-uploaded application, which can still lead to problems with actions and environment deletion.

The proposition is to not delete the packages (or never delete packages, that have apps/libraries deployed into some env, if possible). Instead of deleting a package — it can be marked as "deleted".

This leads to a naming issue, because currently there can only be one package with certain fqn in a tenant and only one public package with certain fqn. This issue can be solved by assigning unique names instead of fqn for deleted packages/classes or by altering the way packages are queried in the db (since the restrictions are imposed on python level, not on db: we can try to alter queries to ignore deleted apps, where appropriate)

To make use of this change client, engine, and api have to be changed to request packages by their id instead of fqn. This would allow to load packages that were marked as deleted even though it would be impossible to deploy an application, that was deleted.
On the other hand package updating becomes impossible, for example user would not be able to re-upload package with updated actions. This can be mitigated by first fetching non-deleted package by fqn and (if not found) fetching package by id.

To allow actual deletion of packages from database we should track number of deployments that use the package and only delete the package if no environment is using it.