- should close dragoon/komodo#3
- based on top of dragoon/komodo!12

> **Note**  
> - commits containing "_DEBUG_" will be removed once this is done
> - this MR is based on dragoon/komodo!12 and will be rebased on top of `main` once dragoon/komodo!12 lands

i think this is best [reviewed commit by commit](dragoon/komodo!13 (58cec473))

this MR uses a simpler `Vec` of `E::ScalarField` to represent a linear combination.

the rest of the crate has been fixed accordingly.

the goal is to let Arkworks do as much work as possible, fixing part of #2.
- `one_more` removed from `field::split_data_into_field_elements` in 5531b31a
- `one_less` removed from `field::merge_elements_into_bytes` in 5761b784

## examples
let's say we have at most $k = 3$ source shards, called $s_0$, $s_1$ and $s_2$ respectively.
this first means that all linear combinations will be at most of length 3.

if a new shard $s$ is a linear combination of the source shards, e.g. $s = \alpha s_0 + \beta s_1 + \gamma s_2$, where $\alpha$, $\beta$ and $\gamma$ are scalar elements of an elliptic curve, then the linear combination in the code will be
```rust
vec![alpha, beta, gamma]
```
> **Note**  
> the right of the vector can be truncated to remove zero elements that are not part of the linear combination and don't add any extra useful information.  
> the left stays mandatory.

e.g. we create two times a linear combination with a single one set to $1$ and the rest to $0$ with the following snippet
```rust
let mut linear_combination = Vec::new();
linear_combination.resize(i + 1, E::ScalarField::zero());
linear_combination[i] = E::ScalarField::one();
```

related to
- dragoon/komodo!13

## description
in dragoon/komodo!13, i noticed that decoding can be pretty sensitive to the order of the shards...
this is why i thought testing all possible permutations of the shards could be beneficial 🤔

see the [run attached to this MR](https://gitlab.isae-supaero.fr/dragoon/komodo/-/jobs/11281#L1120) to see all the combinations of shards used in the tests, e.g. `[0, 2, 3]` means that shards `0`, `2` and `3` have been used and shards `1` and `4` have been "_lost_" 

## changelog
this MR
- adds an inline `math` module to `tests/cli.nu` which defines
  - `choose` which computes all the sets of $k$ choose $n$ in $[|0, ..., n - 1|]$
  - `perm` which computes all the permutations on $[|0, ..., n - 1|]$
  - see the inline `_test_choose` and `_test_perm` commands for concrete examples of their behaviours
- compute all the permutation of $k'$ choose $n$ shards, where $k'$ ranges from $k$ to $n$
- run the reconstruction test on all these cases
- moves the CLI example from `README.md` to `examples/cli.nu`

> **Note**  
> also removes the newline added to the stdout of `komodo` commands, so that the output is prettier, without spurious empty lines

this MR
- uses the Nushell script in the README to test the application in a real CLI context
- bumps the Rust toolchain to 1.72.1
- installs Nushell version 0.89.0 into the CI
- runs the test script

related to
- https://github.com/nushell/nushell/pull/11289

this is to make the passing of bytes easier as `cargo run` wants strings.

# changelog
- add a `transpose` boolean switch to `fec::decode`
- add end to end tests that should reflect the real case scenario of `komodo.nu`

should fix #1 

## changelog
- don't transpose back the decoded shard matrix
- pad the field elements in the test
- run the tests from the min number of bytes to the full length

this should simplify the `fec.rs` test module by removing the long hardcoded vector of bytes.

# changelog
- refactor $k$ and $n$ into variables
- run the decoding FEC test in a loop from $(k - 1) \rho + 1$ to $k \rho$, where $\rho$ is the curve number of bytes per scalar field element, e.g. $31$ for _BLS-12-381_
- add a _NOTE_ about having too few bytes and elements, i.e. below $(k - 1) \rho + 1$
- add a _FIXME_ about having too many bytes and elements, i.e. above $k \rho$

# changelog
- rename `LinalgError` to a more general `KomodoError`
- move `KomodoError` to `error.rs` module
- add a `TooFewShard(usize, usize)` variant

follow up to !3

## description
in !3, to make Clippy happy, `expect` was replace with `unwrap_or_else`, but that suppresses the message of the underlying error, which is not great...

this MR reverts this part of !3 and allows `clippy::expect_fun_call`.

# changelog
- make the FEC decoding test more generic by accepting bytes and encoding by itself
- define a large `BYTES` constant that holds _random_ bytes
- calls the template on a slice of `BYTES`

# changelog
- add a `one_less` argument to `field::merge_elements_into_bytes` to mirror the `one_more` from `field::split_data_into_field_elements`
- add a `linalg` module which defines
  - a `pub LinalgError` enum
  - a `pub(super) Matrix` structure implement for any `ark_ff::Field`, e.g. `<Bls12_381 as Pairing>::ScalarField`
  - `pub(super) Matrix::vandermonde`
  - `pub(super) Matrix::from_vec_vec`
  - `pub(super) Matrix::invert`
  - `pub(super) Matrix::mul`
  - `pub(super) Matrix::transpose`
  - everything is tested extensively
- modify `fec.rs` to use `linalg::Matrix` instead of `reed-solomon-erasure` => tests still pass
- remove the dependency to [`reed-solomon-erasure`](https://github.com/jdetchart/reed-solomon-erasure) completely