feat(contracts): PluginRepo refactor part II

[josemarinas]

Description

• contains many external functions that are not part of IPluginRepo
• being able to specify an initialVersion making

Task ID: OS-1330

Type of change

See the framework lifecycle in packages/contracts/docs/framework-lifecycle to decide what kind of change this pull request is.

• New feature (non-breaking change which adds functionality)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran all tests with success and extended them if necessary.
• I have updated the CHANGELOG.md file in the root folder.
• I have updated the DEPLOYMENT_CHECKLIST file in the root folder.
• I have updated the UPDATE_CHECKLIST file in the root folder.
• I have updated the Subgraph and added a QA URL to the description of this PR.

[clauBv23]

my insights on this matter

Currently, the createVersion function handles both the creation of new plugin versions and the definition of the initial one if none exists. However, with the upcoming addition of the ability to initialize plugin versions to specific builds, it might be a good time to separate these duties.

The idea would be to redefine the responsibilities of the createVersion function to focus solely on generating new plugin versions based on provided release information. And introduce a new function, initializePluginVersion (or a similar name), dedicated exclusively to initializing plugin versions to specific releases and builds, or to the first one if they are zero.

This new function will be called only once because is for initialization purposes only, while the createVersion one could be called every time a new version is needed.

[jordaniza]

convention is to prefix internal variables and methods with an underscore