This pull request is based on #62 (thanks @rorozcov!) and introduces a
new Roslyn analyzer to enforce best practices for member initializers
and assignment statements in C#. The analyzer identifies cases where a
member variable and constructor have duplicate or divergent logic,
leading to extra work being done by the runtime.

## Changes

- Analyzer: `PreferMemberInitializerAnalyzer`:
  - Detects duplicate member variable assignment and initialization
- Detects member variable assignment from a constructor that could be
done at declaration
- Accounts for complex control flow and variable usage to limit false
positives
- Code fix provider: None
- The initialization logic of applications can be complex and a code fix
provider can be complex to capture all cases of remediation. This
implementation only shows areas of potential duplication.
- Tests: Comprehensive unit tests covering various scenarios

This analyzer aligns modern C# and .NET practices, particularly [CA1805:
Do not initialize
unnecessarily](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1805)
and Effective C# Item 12: Prefer member initializers to assignment
statements.

Closes #36 

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit


- **New Features**
- Introduced a new diagnostic analyzer to enforce the use of member
initializers over assignment statements in constructors, improving code
clarity and maintainability.
	- Added performance benchmarking capabilities for the new analyzer.

- **Documentation**
- Added guidelines for the new coding rule (ECS1200) emphasizing member
initializers, including examples and best practices.

- **Bug Fixes**
- Enhanced diagnostic capabilities to accurately identify redundant
initializations and improve overall code quality.

- **Tests**
- Implemented a comprehensive suite of unit tests for the new analyzer,
covering various initialization scenarios and ensuring adherence to best
practices.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Rodolfo Orozco Vasquez <44987991+rorozcov@users.noreply.github.com>
Co-authored-by: Rodolfo Orozco Vasquez <44987991+rorozco1997@users.noreply.github.com>
Co-authored-by: Rodolfo Orozco Vasquez <44987991+rorozcov@users.noreply.github.com>

Signed-off-by: Richard Murillo <rjmurillo@gmail.com>

Enhanced performance testing flexibility by allowing the .NET runtime to
select compatible framework versions with the addition of the
`--roll-forward Major` option.
 
Fixes #64

Signed-off-by: Richard Murillo <rjmurillo@gmail.com>

Updates the shipping `.globalconfig` to enable CA1063 as Warning

Resolves #60

This pull request introduced a new Roslyn analyzer to enforce best
practices for static member initializers and assignments in C#. The
analyzer identifies cases where a member variable is static and complex,
indicating it should move to the type's static constructor.

## Changes

- Analyzer `StaticClassMemberInitializationAnalyzer`:
  - Detects `static` member variable assignment and initialization
- Detects member variable assignment from methods, suggesting complex
cases move to the type's static constructor
- Code fix provider: None
- The initialization logic of applications can be complex and a code fix
provider can be equally complex to capture all cases of remediation.
This implementation only shows areas of potential issue.
- Tests: Added comprehensive unit tests for the new static class member
initialization analyzer to ensure proper functionality and coverage.
Includes benchmarking tests to evaluate the performance of the static
member initialization analyzer.

Closed #56

Update `.globalconfig` to enable CA2214 with Warning severity

Closes #59

…commitid (#69)

This pull request introduces a new Roslyn analyzer to enforce best
practices for C# constructors. The analyzer identifies cases where a
constructor contains duplicate initialization logic as another
constructor.

## Changes

- Analyzer: `MinimizeDuplicateInitializationLogicAnalyzer`:
  -  Detects duplicate initialization statements
- Code fix provider: None
- The initialization logic of applications can be complex and a code fix
provider can be equally complex to capture all cases of remediation.
This implementation only shows areas of potential duplication.
- Tests: Unit tests covering various positive and negative cases

Closes #57

---------

Signed-off-by: Richard Murillo <rjmurillo@gmail.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

Related to #70

Related to #70, #71