feat: add SHAFT model with MECHANICAL_EFFICIENCY for compressor trains

[kjbrak]

Type of Work

• Patch: X.Y.Z+1. NEGLIGIBLE visible changes, does not change input or output - OR changes behaviour. Use chore:, refactor: etc
• Minor: X.Y+1.Z. Minor changes, might ADD new input (YAML), or other backwards-compatible changes. Use feat:, fix:
• Major: X+1.Y.Z. Major and most likely BREAKING changes, wo. backwards compatibility, or removing temporary backwards compatibility functionality. Use ! or BREAKING:.

See here (internal): https://github.com/equinor/ecalc-internal/discussions/1044

Have you remembered and considered?

• IF FEAT: I have remembered to update documentation
• IF FIX OR FEAT: I have remembered to update manual changelog (docs/drafts/next.draft.md)
• IF BREAKING: I have remembered to update migration guide (docs/docs/migration_guides/)
• IF BREAKING: I have committed with BREAKING: in footer or ! in header
• I have added tests (if not, comment why)
• I have used conventional commits syntax (if you squash, make sure that conventional commit is used)
• I have included the Github issue nr in the footer!

What is this PR all about?

Adds a `SHAFT` model type that compressor trains reference for mechanical efficiency. Shaft yaml object might later be used to give flexibility to let solver infer which compressors share shaft and hence speed (or speed coupling via gear ratio or similar concepts).

Changes

• Add `SHAFT` model type with `MECHANICAL_EFFICIENCY` field
• Add `MECHANICAL_EFFICIENCY` directly to simplified trains
• Add deprecation warnings for `POWER_ADJUSTMENT_CONSTANT/FACTOR`
• Add validation for mutual exclusivity
• Update documentation with migration guide

Example

```yaml
MODELS:
  - NAME: my_shaft
    TYPE: SHAFT
    MECHANICAL_EFFICIENCY: 0.95

  - NAME: my_train
    TYPE: VARIABLE_SPEED_COMPRESSOR_TRAIN
    SHAFT: my_shaft
    ...
```

What else did you consider?

See also: #TBD (alternative approach with direct MECHANICAL_EFFICIENCY) on train"