[All] Add support for TreatWarningsAsErrors

[MangelMaxime]

This PR tries to re-enable TreatWarningsAsErrors, this is really handy feature and becoming even more important with nullness supports to make nullness really strict.

We mimic the behavior at Fable level, because we can pass the option to FCS otherwise it will also report errors from libraries/packages code which the user have no control over.

#2521

[MangelMaxime]

If we wanted to avoid this cases, we should need to rework the LogEntry type from a record:

type LogEntry =
    {
        Message: string
        Tag: string
        Severity: Severity
        Range: SourceLocation option
        FileName: string option
    }

into a union

type LogData =
    {
        Message: string
        Tag: string
        Range: SourceLocation option
        FileName: string option
    }
	

type LogEntry = 
	| Error of LogData
	| Warning of LogData
	| Info of LogData

I am not sure if this is worth doing or not

[MangelMaxime]

If we wanted to add integration tests for this feature we would need to make a NuGet package with warnings inside of it to check that do ignore them and don't report them as errors.

The previous implementation could have been tested the same way, so for now for simplicity I think we can avoid going down that path for simplicity. If later, we found issues with the implementation or want to prevent regression we can allocate some time to try crafting a test suit for both warnings and errors output of Fable.

[MangelMaxime]

@nojaf @Freymaurer @jkone27

I believe you will need to port this code into vite-plugin-fable.

As support for TreatWarningsAsErrors has been tried several times in the past and disabled, if I were you I would wait before porting it to make sure that this implementation is correct and stable.

[Freymaurer]

Let me know when! 🙂

[MangelMaxime]

I am going to merge this PR as is, because more "real world testing" is needed to gather feedback.

There are several things that could be improve once we know it works:

1. Avoid doing the array concatenation at the end of startCompilationAsync
2. Adapt the integration tests, and we should probably simplify then if possible