feat: add MECHANICAL_EFFICIENCY to compressor train types

[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?

Summary

Add MECHANICAL_EFFICIENCY parameter directly to all compressor train types as a physically meaningful alternative to the deprecated POWER_ADJUSTMENT_FACTOR and POWER_ADJUSTMENT_CONSTANT parameters.

Changes

• Add MECHANICAL_EFFICIENCY field (0 < η ≤ 1, default 1.0) to all 4 train types
• Extend Shaft domain class to own mechanical efficiency
• Calculate shaft_power = gas_power / mechanical_efficiency in stage results
• Add deprecation warnings for POWER_ADJUSTMENT_CONSTANT/FACTOR
• Add validation for mutual exclusivity (can't combine old and new params)
• Update documentation with migration guide and reference docs

Example

```yaml
MODELS:
  - NAME: export_compressor
    TYPE: VARIABLE_SPEED_COMPRESSOR_TRAIN
    MECHANICAL_EFFICIENCY: 0.95  # 5% mechanical losses
    FLUID_MODEL: medium_gas
    COMPRESSOR_TRAIN:
      STAGES:
        - INLET_TEMPERATURE: 30
          COMPRESSOR_CHART: chart_ref

Supported train types

• VARIABLE_SPEED_COMPRESSOR_TRAIN
• SINGLE_SPEED_COMPRESSOR_TRAIN
• SIMPLIFIED_VARIABLE_SPEED_COMPRESSOR_TRAIN
• VARIABLE_SPEED_COMPRESSOR_TRAIN_MULTIPLE_STREAMS_AND_PRESSURES

What else did you consider?

See also: #TBD (alternative approach with separate SHAFT model type referenced via SHAFT: shaft_name)