Add GitExtensions.Extensibility

[RussKie]

Proposed changes

• The initial move of all shared contracts and helper API to https://github.com/gitextensions/gitextensions.extensibility (see Move API contracts and definitions from GitExtensions repo gitextensions.extensibility#31). Create a new project called Gitextensions.Extensibility and move of all shared contracts and helper API.
• Updated namespaces.

This change allows for a separation of concerns - shared contracts that affect the main app as well as Git Extensions plugins will now reside in Gitextensions.Extensibility project, and concrete implementations of the contracts reside in the app.
This is a stepping stone in a direction of complete separation of the contracts and future move of those to https://github.com/gitextensions/gitextensions.extensibility project.

I expect further work will be required to clean the contract declarations (e.g., removal of default args as those play tricks on developers) as well as a holistic reassessment of the API surface.

Merge strategy

I agree that the maintainer squash merge this PR (if the commit message is clear).

---

✒️ I contribute this code under The Developer Certificate of Origin.

[mstv]

There must be a very huge benefit of moving all these interfaces and utilities to a submodule / NuGet package.
Could you elaborate the benefits, please? Where do you draw the line between things exposed to plugins and the internal, more changeable implementation.
They need to compensate for the friction added by switching to/from submodules and by split PRs.

[gerhardol]

This will make development of the core app annoying, will slow down the app for the benefit of a few plugins. Most moved functionality does not make sense in a module, for instance GitModule have mostly app internal functions.
This will lead to duplicated code.

[mstv]

It should not be too difficult to directly publish the GE Extensibility NuGet from the GE main repo, shouldn't it?

[gerhardol]

With this, you know if the plugins require changes after a GE update. On the other hand, there are so much core functionality in Extensibility that the plugins will always have to be updated.
There are easier ways to achieve the strict compatibility without limiting the core app development.
Of course, the plugin functionality could be limited (more like other interfaces?), but it would not be better for plugins.

Adding plugins to an existing app without a designed interface is not smooth.

[mstv]

this is precisely why I want the complete segregation of the interfaces and implementations so that we have design discussions and come up with API that both age gracefully with time, provide a solid foundation for extensibility and provide coherent and meaningful contract.

I fully support this! But I have concerns / objections to move them out of the repo. I still think my above comments are clear.

[RussKie]

Apologies for the radio silence; the end of last year was very demanding and draining (mentally and physically). Right now I'm on a vacation with a very limited access to a computer. I will respond to the feedback and questions when I'm back in about a month.

[RussKie]

I rebased the changeset and split it in a way that should make the review easy. You can safely skip over 598072e, c4c65da and f9c9244 as those were mechanical auto-fixer changes.

[mstv]

LGTM
I have fixed the first three comments myself.

[RussKie]

Thank you @mstv