chore(docs): update docusaurus (#1485)

## Type of Work

- [x] 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:.

## 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)
- [x] 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?

* Updated Docusaurus from `3.9.2` to `3.10.0` ([release notes here](https://docusaurus.io/blog/releases/3.10))
* Since Docusaurus is moving away from proprietary syntax, heading ids had to be changed ([link](https://docusaurus.io/blog/releases/3.10#strict-heading-ids)). So I ran the command `npx docusaurus write-heading-ids --syntax mdx-comment --migrate` to update all heading ids:

```mdx
-## My Heading {#my-id}
+## My Heading {/* #my-id */}
```

This changed the old ids' syntax, but also created heading ids for all headings. But I think that is a good thing?

* Overriding a couple of transitive dependencies to fix high and moderate vulnerabilities
  *  `serialize-javascript` version `7.0.5` to fix https://github.com/equinor/ecalc/security/dependabot/59 (overriding the peer dependency is safe [link](facebook/docusaurus#11801 (comment)))
  * `lodash-es` version `4.18.1`to fix https://github.com/equinor/ecalc/security/dependabot/62 and https://github.com/equinor/ecalc/security/dependabot/63

## What else did you consider?

We should rename all our `.md` files to `.mdx`, [see documentation here](https://docusaurus.io/blog/releases/3.10#strict-mdx), but this should be done in another PR

## Between the lines?

Author: rodsjo

docs/docs/about/getting_started/cli/cli_reference.md

@@ -30,7 +30,7 @@ $ ecalc [OPTIONS] COMMAND [ARGS]...
 * `selftest`: Test that eCalc has been successfully...
 * `show`: Command to show information in the model...
 
-## `ecalc run`
+## `ecalc run` {/* #ecalc-run */}
 
 **Usage**:
 
@@ -56,7 +56,7 @@ $ ecalc run [OPTIONS] MODEL_FILE
 * `--date-format-option [0|1|2]`: Date format option. 0: "YYYY-MM-DD HH:MM:SS" (Accepted variant of ISO8601), 1: "YYYYMMDD HH:MM:SS" (ISO8601), 2: "DD.MM.YYYY HH:MM:SS". Default 0 (ISO 8601)  [default: 0]
 * `--help`: Show this message and exit.
 
-## `ecalc selftest`
+## `ecalc selftest` {/* #ecalc-selftest */}
 
 Test that eCalc has been successfully installed
 
@@ -70,7 +70,7 @@ $ ecalc selftest [OPTIONS]
 
 * `--help`: Show this message and exit.
 
-## `ecalc show`
+## `ecalc show` {/* #ecalc-show */}
 
 Command to show information in the model or results.
 
@@ -89,7 +89,7 @@ $ ecalc show [OPTIONS] COMMAND [ARGS]...
 * `results`: Show results.
 * `yaml`: Show yaml model.
 
-### `ecalc show results`
+### `ecalc show results` {/* #ecalc-show-results */}
 
 Show results. You need to run eCalc™ before this will be available.
 
@@ -110,7 +110,7 @@ $ ecalc show results [OPTIONS]
 * `-f, --output-frequency [NONE|YEAR|MONTH|DAY]`: Frequency of output. Options are DAY, MONTH, YEAR. If not specified, it will give time steps equal to the union of all input given with INFLUENCE_TIME_VECTOR set to True. Down-sampling the result may lead to loss of data, and rates such as MW may not add up to cumulative values  [default: NONE]
 * `--help`: Show this message and exit.
 
-### `ecalc show yaml`
+### `ecalc show yaml` {/* #ecalc-show-yaml */}
 
 Show yaml model. This will show the yaml after processing !include.
 

docs/docs/about/getting_started/cli/faq.md

@@ -6,11 +6,11 @@ description: eCalc FAQ
 While running eCalc as a Unix command-line tool, you may come across seemingly incomprehensible error messages.
 This page tries to explain some common error messages and proposes how to fix them.
 
-## Indentation errors
+## Indentation errors {/* #indentation-errors */}
 In YAML, the indentation is very important and specifies the level in the hierarchy for the input.
 If you have the wrong indentation somewhere, you may get both YAML read errors and/or eCalc setup errors.
 
-### Error messages due to YAML read problems
+### Error messages due to YAML read problems {/* #error-messages-due-to-yaml-read-problems */}
 The following error messages are common when you have formatting issues in your YAML file:
 
 ~~~~~~~~text
@@ -27,7 +27,7 @@ while parsing a block mapping in <setupfile>, line <n>, column <m>
 expected <block end>, but found '<block mapping start>'
 ~~~~~~~~
 
-### Error messages due to invalid eCalc configuration
+### Error messages due to invalid eCalc configuration {/* #error-messages-due-to-invalid-ecalc-configuration */}
 The configuration expects a sub-hierarchy of data. After reading YAML, this data sub-hierarchy would be of object type
 dictionary (dict) and in some cases contain lists or other objects. If invalid data is input, the error message would
 indicate that the type is wrong because it is not a 'dict'/'list' or other type
@@ -40,10 +40,10 @@ None should be instance of 'dict'
 None should be instance of 'list'
 ~~~~~~~~
 
-### Proposed solution
+### Proposed solution {/* #proposed-solution */}
 Check your YAML setup file for correct indentation and correct format of values for each eCalc key.
 
-## Special characters in Unicode
+## Special characters in Unicode {/* #special-characters-in-unicode */}
 eCalc uses [ruamel.yaml](https://pypi.org/project/ruamel.yaml/) to read the YAML setup files. Some (text) files have an encoding not supported and will thus result in an error message.
 
 One example of this is an unrecognized "[BOM](https://en.wikipedia.org/wiki/Byte_order_mark)" character in "[UTF-8 Unicode](https://nl.wikipedia.org/wiki/UTF-8)".
@@ -55,7 +55,7 @@ while scanning a simple key in "<setupfile.yml>", line <n>, column 1
 could not find expected ':', line <n>, column 1
 ~~~~~~~~
 
-### Proposed solution
+### Proposed solution {/* #proposed-solution-1 */}
 Check the encoding of your setupfile (and inputfiles):
 
 ~~~~~~~~bash

docs/docs/about/getting_started/cli/index.md

@@ -16,9 +16,9 @@ You must minimum have **Python 3.11** installed to use eCalc.
 
 See all commands and options in the [CLI reference](/about/getting_started/cli/cli_reference.md)
 
-## Example Usage
+## Example Usage {/* #example-usage */}
 
-#### Use show command to inspect results
+#### Use show command to inspect results {/* #use-show-command-to-inspect-results */}
 
 First run ecalc (here shown with default output folder)
 
@@ -50,22 +50,22 @@ or write the full csv result to a file (this will give the same output as `ecalc
 $ ecalc show results --output-format csv --file results.csv
 ~~~~~~~~
 
-#### Output Monthly CSV data
+#### Output Monthly CSV data {/* #output-monthly-csv-data */}
 ~~~~~~~~bash
 $ ecalc run -f MONTH /somelocation/myfield.yml
 ~~~~~~~~
 
-#### Specify different output folder
+#### Specify different output folder {/* #specify-different-output-folder */}
 ~~~~~~~~bash
 $ ecalc run -o /somedirectory/foo/bar/ /somelocation/myfield.yml
 ~~~~~~~~
 
-#### Specify a different naming prefix to outputs
+#### Specify a different naming prefix to outputs {/* #specify-a-different-naming-prefix-to-outputs */}
 ~~~~~~~~bash
 $ ecalc run -n myfield_myproject /somelocation/myfield.yml
 ~~~~~~~~
 
-#### Show stack trace for debugging
+#### Show stack trace for debugging {/* #show-stack-trace-for-debugging */}
 ~~~~~~~~bash
 $ ecalc run --log DEBUG /somelocation/myfield.yml
 ~~~~~~~~

docs/docs/about/index.md

@@ -9,7 +9,7 @@ description: Introduction to eCalc documentation
 
 The eCalc™ technology is being developed by Equinor within the Technology, Digital and Innovation (TDI) business area.
 
-## What is eCalc™?
+## What is eCalc™? {/* #what-is-ecalc */}
 eCalc™ is a software tool for calculation of energy demand and greenhouse gas emissions from oil and gas production and processing. It enables the cross-disciplinary collaboration required to achieve high-quality and transparent energy and GHG emission prognosis and decision support.
 
 eCalc™ performs energy and emission calculations by integrating data, knowledge and future plans from different disciplines. This could be production and injection profiles from the reservoir engineer, characteristics of energy consuming equipment units such as gas turbines, compressors and pumps from the facility engineer, and emission factors for different fuels from the sustainability engineer. The main idea is using physical or data-driven models to relate production rates and pressures to the required processing energy and resulting emissions. Integrated bookkeeping for all emission sources is offered.
@@ -19,10 +19,10 @@ eCalc™ uses a bottom-up approach to give high-quality installation and portfol
 ![](ecalc_illustration.svg)
 
 
-### Why should I use eCalc™?
+### Why should I use eCalc™? {/* #why-should-i-use-ecalc */}
 By using eCalc™ you will be able to forecast your energy consumption and emissions with consistency and transparency. You will also be enabled to study the effect on energy demand and emissions of your investment opportunities as well as studying emission reduction measures.
 
-### How to use eCalc™?
+### How to use eCalc™? {/* #how-to-use-ecalc */}
 To use eCalc™ you need to create a model setup of your asset.
 This is described in the [Modelling](/about/modelling/index.md) section.
 

docs/docs/about/migration_guides/v10.0_to_v11.0.md

@@ -6,7 +6,7 @@ sidebar_position: -14
 
 # v10.0 to v11.0
 
-### Migration overview
+### Migration overview {/* #migration-overview */}
 
 - Make sure that `NAME` across your model is **UNIQUE**
 - Make sure that `PRESSURE` is > 0 if `RATE` > 0

docs/docs/about/migration_guides/v11.0_to_v12.0.md

@@ -6,7 +6,7 @@ sidebar_position: -15
 
 # v11.0 to v12.0
 
-### Migration overview
+### Migration overview {/* #migration-overview */}
 
 - If you have been using `GENERIC_FROM_INPUT` in a `SIMPLIFIED_COMPRESSOR_TRAIN` either directly or indirectly (e.g. through `COMPRESSOR_WITH_TURBINE`), you
 will either need to

docs/docs/about/migration_guides/v12.0_to_v13.0.md

@@ -6,9 +6,9 @@ sidebar_position: -16
 
 # v12.0 to v13.0
 
-### Migration overview
+### Migration overview {/* #migration-overview */}
 
-#### Migrate ADJUSTMENT section for FACILITY_INPUTS
+#### Migrate ADJUSTMENT section for FACILITY_INPUTS {/* #migrate-adjustment-section-for-facility_inputs */}
 
 If you have been using [ADJUSTMENT](../references/ADJUSTMENT) section for `FACILITY_INPUTS`, you will need to adjust your input data accordingly, as this section has been removed in v13.0).
 

docs/docs/about/migration_guides/v7_to_v8.md

@@ -11,22 +11,22 @@ In this migration guide you will find:
 1. [YAML changes](#yaml-migration)
 2. [CLI changes](#cli-migration)
 
-## Yaml migration
+## Yaml migration {/* #yaml-migration */}
 
-### Migration overview
+### Migration overview {/* #migration-overview */}
 
 This doc guides you through migrating an existing eCalc™ model from version v7 to v8.
 
 We try to make this as easy as possible, and provide a step-by-step migration guide.
 
-### Main differences
+### Main differences {/* #main-differences */}
 1. All component names must be unique to avoid ambiguity in reporting
 2. UNITS are required when setting up compressor and pump charts
 3. Restrict allowed characters in component names and emission names
 4. NAME no longer used for LTP reporting, use CATEGORY instead
 5. Not possible to use custom category names, pre-defined categories must be uppercase with hyphen as separator (i.e. FUEL-GAS)
 
-#### 1. All component names must be unique
+#### 1. All component names must be unique {/* #1-all-component-names-must-be-unique */}
 
 All component names must be unique in order to avoid ambiguity in reporting. Components include asset/ecalc-model, installation,
 generator sets, electricity consumers, fuel consumers and direct emitters.
@@ -141,7 +141,7 @@ CATEGORY:
 See [Power from shore](../modelling/setup/installations/generator_sets_in_calculations.md#power-from-shore) for more information.
 :::
 
-#### 2. UNITS for pump and compressor charts
+#### 2. UNITS for pump and compressor charts {/* #2-units-for-pump-and-compressor-charts */}
 
 Compressor and pump charts has previously had implicit units, without requiring the operator to specify what
 units are actually being used. This increases the risk of wrong specification, and makes it more difficult to hand
@@ -210,14 +210,14 @@ and [PUMP CHART](../modelling/setup/facility_inputs/pump_modelling/pump_charts)
 for more details about the relevant keywords.
 
 
-#### 3. Restrict allowed characters in component names and emission names
+#### 3. Restrict allowed characters in component names and emission names {/* #3-restrict-allowed-characters-in-component-names-and-emission-names */}
 
 Component names can now only consist of letters (a-z, upper and lower case), numbers (0-9), underscore (`_`), hyphen (`-`) and space (` `).
 
 Emission names can now only consist of letters (a-z, upper and lower case), numbers (0-9) and underscore (`_`).
 
 
-#### 4. NAME no longer used for LTP reporting, use CATEGORY instead
+#### 4. NAME no longer used for LTP reporting, use CATEGORY instead {/* #4-name-no-longer-used-for-ltp-reporting-use-category-instead */}
 
 We have categories for FLARE and COLD-VENTING-FUGITIVE, and have introduced categories for LOADING and STORAGE. These should now be used instead of NAME.
 
@@ -275,12 +275,12 @@ INSTALLATIONS:
 ```
 
 
-#### 5. Not possible to use custom category names, pre-defined categories must be uppercase with hyphen as separator (i.e. FUEL-GAS)
+#### 5. Not possible to use custom category names, pre-defined categories must be uppercase with hyphen as separator (i.e. FUEL-GAS) {/* #5-not-possible-to-use-custom-category-names-pre-defined-categories-must-be-uppercase-with-hyphen-as-separator-ie-fuel-gas */}
 
 Only a limited pre-defined set of categories is valid input to the CATEGORY-keyword, it is no longer possible to use custom names. 
 The input is case-sensitive and must match exactly with the pre-defined names. See [CLI Docs](../references/CATEGORY) for full documentation.
 
-## CLI migration
+## CLI migration {/* #cli-migration */}
 
 This version includes some changes to how the CLI is invoked and changes to default behavior.
 
@@ -291,7 +291,7 @@ This version includes some changes to how the CLI is invoked and changes to defa
 5. Argument for LTP export has changed from: `--centuries-ltp-export` to `--ltp-export`
 6. Simple results are now default for json
 
-#### 1. Invoking eCalc™ directly is no longer supported, use `ecalc run` instead.
+#### 1. Invoking eCalc™ directly is no longer supported, use `ecalc run` instead. {/* #1-invoking-ecalc-directly-is-no-longer-supported-use-ecalc-run-instead */}
 
 To make it possible to add `ecalc show` we added the `ecalc run` command. In v8 it is required to specify `run` when calculating a model.
 
@@ -307,7 +307,7 @@ you should now use
 $ ecalc run ./my-model.yaml
 ~~~~~~~~
 
-#### 2. Log level should be specified as the first argument + log to file
+#### 2. Log level should be specified as the first argument + log to file {/* #2-log-level-should-be-specified-as-the-first-argument--log-to-file */}
 
 Previously you could specify the `--log` argument after `run`, this is no longer possible.
 
@@ -329,27 +329,27 @@ $ ecalc --log DEBUG --log-folder . run ./my-model.yaml
 
 As you see above, the argument **MUST** be added **BEFORE** the `run` argument.
 
-#### 3. Model yaml-file needs to come last
+#### 3. Model yaml-file needs to come last {/* #3-model-yaml-file-needs-to-come-last */}
 
 When running eCalc™ you will now need to set the model file argument last.
 
 `ecalc [OPTIONS] COMMAND [ARGS] [MODEL YAML-file]`
 
 See the [CLI Docs](../getting_started/cli/cli_reference) or run `ecalc --help` for the full documentation.
 
-#### 4. Extrapolation correction is no longer optional
+#### 4. Extrapolation correction is no longer optional {/* #4-extrapolation-correction-is-no-longer-optional */}
 
 We have removed the extrapolation correction argument. eCalc™ will now always "extrapolate" values.
 The main reason for making this change was that the feature was in general always used, in addition to being a confusing term. 
 Let us know if you have a use-case where this was needed.
 
-#### 5. Argument for LTP export has changed from: `--centuries-ltp-export` to `--ltp-export`
+#### 5. Argument for LTP export has changed from: `--centuries-ltp-export` to `--ltp-export` {/* #5-argument-for-ltp-export-has-changed-from---centuries-ltp-export-to---ltp-export */}
 
 To prepare for Open Source and to make the LTP export more agnostic (even though the column names are heavily 
 affected by Centuries), we simplify the argument to get LTP results. See [CLI Docs](../getting_started/cli/cli_reference) for 
 full documentation.
 
-#### 6. Simple results are now default for json
+#### 6. Simple results are now default for json {/* #6-simple-results-are-now-default-for-json */}
 Detailed output (or any json) should mainly be used for QA and advanced users, and is no longer shown by default. To keep old behavior, the user now
 needs to use the --detailed-output option when running the CLI. See [CLI reference docs](../getting_started/cli/cli_reference#ecalc-run)
 for more details.

docs/docs/about/migration_guides/v8-0_to_v81.md

@@ -10,15 +10,15 @@ In this migration guide you will find:
 
 1. [YAML changes](#yaml-migration)
 
-## Yaml migration
+## Yaml migration {/* #yaml-migration */}
 
-### Migration overview
+### Migration overview {/* #migration-overview */}
 
 This doc guides you through migrating an existing eCalc™ model from version v8 to v8.1.
 
 We try to make this as easy as possible, and provide a step-by-step migration guide.
 
-### 1. Changes to TIME_SERIES
+### 1. Changes to TIME_SERIES {/* #1-changes-to-time_series */}
 - `RATE_INTERPOLATION_TYPE` is renamed to [`INTERPOLATION_TYPE`](../references/INTERPOLATION_TYPE)
 - New time series type: `DEFAULT` with default `RIGHT` interpolation
 - `RESERVOIR` type is removed
@@ -83,7 +83,7 @@ somebody that can help you out to make this right. The consequences of doing it
 easily offset by 1 year.
 :::
 
-### 2. Not possible to have different interpolation types for vectors within one file
+### 2. Not possible to have different interpolation types for vectors within one file {/* #2-not-possible-to-have-different-interpolation-types-for-vectors-within-one-file */}
 
 Previously eCalc™ tried to recognize vectors as rates- or non-rates for time series.
 Hence, rate-vectors were set to use `LEFT` interpolation type, or if the type was
@@ -98,13 +98,13 @@ rate vectors. If different vectors (e.g. pressures and rates) should be interpol
 to be in separate files.
 :::
 
-### 3. Empty data in time series columns no longer allowed
+### 3. Empty data in time series columns no longer allowed {/* #3-empty-data-in-time-series-columns-no-longer-allowed */}
 
 Each column in a time series resource should have data for all time steps, eCalc™ will now show an error if this is not the case. 
 The reason behind this is that it can be ambiguous to know whether missing data should be interpolated or considered as 0. Now
 users will have to be explicit, and this will lead to fewer ambiguities and errors.
 
-### 4.  New LTP Category: STEAM-TURBINE-GENERATOR
+### 4.  New LTP Category: STEAM-TURBINE-GENERATOR {/* #4--new-ltp-category-steam-turbine-generator */}
 
 A new LTP requirement to report steam turbine generator consumption/generation. This affects the total generator production 
 negatively (reduced load), as some energy is provided through this steam turbine generator. It is therefore modelled as a consumer