Bugfix/exception handling method

[Kaybangz]

Which issue are you addressing?

51

How have you addressed the issue?

This PR introduces a new ValidateParameters method and implements an additional error check in the Parallel.Ordered method to prevent unexpected behavior and improve the reliability of the codebase.

• Added a new ValidateParameters method to validate input parameters, ensuring the correctness of start and end indices, number of threads, chunk size, number of tasks, and grainsize.
• Implemented validation checks in the Parallel.Ordered method to ensure proper usage. If conditions like not being used inside the Parallel.For or Parallel.ForReduction methods are not met, the NotInForException is thrown to provide a clear error message.
• Added Barrier call at the end of Parallel.Ordered

[computablee]

Oooohhhh... merge conflict. I suspected that when I did the refactoring in #86. Let me see what I can do on my end.

[computablee]

Okay, updated list of changes after the tests ran:

1. Ordered should not be a barrier. This will cause a deadlock. I had to cancel the integrations tests check because that happened.
2. In the if statements in ValidateParameters, please have the body of the loop indented on a new line. This doesn't cause a linter error, but I should probably configure the linter such that it does.
3. In Exceptions.cs, please add a space before the : tokens. This causes a linter error.
4. In Parallel.cs, please remove the spaces on line 250. This causes a linter error.

I went ahead and resolved the merge conflict and pushed the results to your fork. Under the new refactoring of For/ForReduction/ForCollapse/ForReductionCollapse, the only place that the parameters validation needs to happen is at the top of the internal For handler, because all of the methods in the public-facing API call this method.