Simplify implementation of new backends

[r4victor]

Currently, adding a new backend involves unnecessary complexity, largely due to the support of legacy features that are no longer needed. The proposal is to make the process of adding a new backend as simple as possible by minimizing dstack-specific knowledge required:

• Move all backend files under the same dir including compute, models, configurator, etc. This should be in the server/ dir since configurators need to import from other server modules, i.e. something like server/services/backends/{backend_name}. Or even better, make backends independent of server functionality – change Configurator not to depend on BackendModel, ProjectModel, etc. Then all backend files can be put in core/backends/{backend_name}.
• Remove Configurator.get_default_configs() – it's not used since we dropped automatic backend configuration.
• Replace Configurator.get_config_values() with a new method that only performs validation. dstack doesn't need to work with partial configs since we dropped interactive backend configuration. Also, remove *WithCredsPartial and *ConfigValues models.
• Simplify config models. *ConfigInfo models are used as API and configurator models and *Config models from services/config.py are used as YAML config models. There are also config models for db and Backend/Compute. For most backends, the configs will be the same. But we still need the flexibility to keep them separate. I suggest we allow defining *Config (yaml), *ConfiguratorConfig, *BackendConfig, *DBConfig models. Most backends would just define one model that will be used for all of them.
• Consider dropping json-based backend configuration endpoints. Simplify backend configurators and models #2389 unifies backend models so that maintaining json endpoints does not add much extra maintenance.
• Consider dropping BackendConfig base class from base/config.py. Move configs from config.py to models.py. Clarify that *Config models are optional backend implementation detail.
• Do not define backend features via lists like BACKENDS_WITH_CREATE_INSTANCE_SUPPORT. Introduce Compute properties that define features. The lists can be built dynamically if required.
• Store BackendType in the db as text instead of enum to avoid migrations when adding a new backend (InstanceModel.backend_type and BackendModel.type).
• Return BackendType as str in the API (or as a enum/str union) to avoid breaking backward compatibility when adding a new backend. Since many models are used as request and response models, replacing enum with str would require validating backend types manually in many places, which would be cumbersome. I suggest we leave it as is since backward compatibility is broken only if someone uses the new backend on the project. It's ok to force everyone to update in that case.

[r4victor]

@olgenn backend-specific forms (aws/azure/gcp/lambda) in frontend/src/pages/Project/Backends/Form can be dropped since the API will be dropping support for non-yaml configuration.

[olgenn]

@olgenn backend-specific forms (aws/azure/gcp/lambda) in frontend/src/pages/Project/Backends/Form can be dropped since the API will be dropping support for non-yaml configuration.

#2423 Done