Thanks to Tarmil!
(fsbolero/Bolero#370 (comment))

### **Description:**

This Pull Request introduces a new output format option: JSON.

### **Motivation:**

Currently, the various output formats in `shader-minifier` are tightly
coupled with the main program. This means that if a user requires a
specific output format that isn't already supported, they need to have
that functionality accepted and merged into the core package. This
approach isn't always the most flexible or user-friendly for everyone.

By adding a JSON output option, users will have a standardized,
machine-readable format. If their desired output format is not natively
supported, they can easily parse the JSON output and generate their
preferred format themselves. This provides greater flexibility and
empowers users to adapt the minifier's output to their specific needs
without requiring direct modifications to this repository for every new
format.

### **A Note on Implementation:**

I am not deeply familiar with F# or the .NET ecosystem, so there's a
possibility that my implementation might not be idiomatic or could be
improved. I would greatly appreciate any feedback, suggestions, or
corrections regarding the code.

close #511 

This PR removes System.Text.Json.JsonSerializer to resolve persistent
build and runtime errors related to its source generator mode in our F#
Blazor WASM setup.

Adds support for multi-dimensional arrays of the form:

```
float x[3][4][8];
```

## Approach

Takes the simple approach of replacing the optional `size` attribute of
the declaration AST with a (potentially empty) `sizes` list.

## Outstanding Issues

### Definition condensing

The `array.frag` unit test contains a case similar to the following
(simplified for example's sake)

```
float a[5];
float b[5];
```

And expects these to be condensed to a shared one line definition

```
float a[5], b[5];
```

Notice, however, that both arrays have the same size. Turns out that, if
you change the size of b to 4, for instance, the definitions still get
condensed.

```
float a[5], b[4];
```

**But this is not valid HLSL (or GLSL, I think?).**

To fix this, I made it so that array definitions of different sizes
can't be compactified. But, this breaks the `array.frag` test, since it
has a few other cases involving arrays with unspecified sizes (i.e.
`c[]`) and arrays with sizes that are evaluated as part of the
minification process (`int size = 2+2; c[size];`).

Looking for feedback here; assuming keeping array definition-sharing in
some capacity is the desired behavior.

### Non-neighboring, Mergeable Definitions

Currently only neighboring definitions are merged. I.e.

```
float a[3];
float b[2];
float c[3];
```

Produces

```
float a[3];
float b[2];
float c[3];
```

I.e. it does not merge a and c into a shared declaration. This seems to
be a function of the way the AST transform is written.

---
- To see the specific tasks where the Asana app for GitHub is being
used, see below:
  - https://app.asana.com/0/0/1210515599774891

This PR adds basic support for parsing struct methods into the AST, and
printing them back out.

## Strategy

The strategy we choose is pretty straightforward. Previously, the AST
for a `StructOrInterfaceBlock` maintained a `Decl list` of _fields_.

We define a new algebraic type:

```
StructMember =
  | MemberVariable of Decl
  | Method of FunctionType * Stmt
```

That can be either a member variable or a method. The AST for
`StructOrInterfaceBlock` changes accordingly:

```
and StructOrInterfaceBlock = {
    // ...
    members: StructMember list
}
```

## Unsupported Features

Method renaming is not supported, though should be implementable in a
way similar to field renaming (EDIT: I actually have this done in a
follow-up).

Methods with separate definitions are not supported, i.e.

```
struct MyStruct {
  int MyFunction();
};

// ... later

int MyStruct::MyFunction() {
  return 4;
}
```

though this is valid HLSL (compilable by FXC and DXC).

Nested structs are not supported, i.e.

```
struct MyStruct {
  struct MyNestedStruct {
    // ...
  };
};
```

This is kind of a non-sequitur, but it's technically valid in HLSL. To
support this I think you'd just have to add `StructOrInterfaceBlock` to
the algebraic type for `StructMember`, and parse it, but this is
orthogonal enough that we'll save that for another day.

…#507)

Hey! I just noticed running `shader_minifier.exe --version` has a
nonzero (error) exit code and thought I'd fix it quickly.

Don't reuse const variables. Fixes #535

When minifying multiple shaders to `--format indented`, the sources are
labeled:
```GLSL
// source1.glsl
...

// source2.glsl
...
```

More inlining opportunities

the files were added in #507

The variable shadowing calculation was sometimes allowing the renaming
to shadow outer names when they were actually used in the inner scope.
This generated invalid minified code.

This happened only after a multi-use-site variable inlining, because it
introduces sharing instances of identifiers at multiple places in the
AST. This was a problem in the renaming because it operated under the
assumption that the inner scope names were not renamed yet when entering
the scope to compute shadowings. But the shared identifier instance was
already renamed when processing its use in the outer scope!

Co-authored-by: Laurent Le Brun <laurentlb@gmail.com>