Refactor library to support thread groups

[scastd]

Describe the feature

This feature will allow creating thread groups with a specified number of threads. Instead of using the ExecutorService interface, we can create our own custom executor that implements even more advanced features.

Additional information

• [X] Would you be willing to help implement this feature?

Final checks

• [X] Read the contribution guide.
• [X] Check existing discussions and issues.

[scastd]

We can also create a specific implementation for the Runnable interface with more attributes (like groupID, name, etc.) and methods.

[scastd]

In addition, a naming refactor will be done in this issue.

[scastd]

[!NOTE] This comment will be updated every time a new change is introduced in this issue during the refactoring process.

• Moved all classes one package up, from jromp.parallel package to jromp package (commit bdf8b2e3).
• Changed the name for the Parallel class to JROMP (commit 7f35a9e3).
• Deleted redundant tests for checkThreads since they are tested in other test class (commit 5b646ede).
• JROMP class improvements by adding a new custom Thread implementation and javadoc (commits ef5785b5, f154b726).
• Thread teams available with new class ThreadTeam (commit 08529cd8).
• Extracted class name to a constant to prevent successive calls to Class.getSimpleName() method (commit f703d7dc).
• Implement a custom executor that wraps a ThreadPoolExecutor as an attribute of ExecutorService type (commit 24d6cc5d).
• Fix, javadoc and test (commits f12525b0 and 0726df8e, 587b1bcf).
• Removed unnecessary withVariables call from a test case (commit 3d6dfeb1).

[scastd]

IMPORTANT: Check what functions we expose in the ThreadTeam class to prevent users from calling them directly and causing unwanted behavior.