Mark add-on store code as public API

[seanbudd]

Initially, the majority of new add-on store code was marked as part of the private API. This was because it was an extremely large change and there were expected and unexpected changes to happen to the code in subsequent releases.

The add-on store was introduced in 2023.2. By the time 2024.1 is released, we can expect the add-on store API to be relatively stable.

[lukaszgo1]

I'm not sure the reasoning given in the initial description makes sense. While we do not have clear guide lines on what is private API, and what should be available to add-on developers, I don't think marking code as public only because it is mature enough is a good metric. Is there any real need for add-ons to make it public? Has this been ever requested? The store is internal part of NVDA, and I have trouble imagining an use case for which it should not be.
I believe the add-on store code should remain private, unless add-on developers asks for some part of it to become public!

[seanbudd]

@lukaszgo1 - yes, an example need is for patching the URL for the add-on store as discussed in #14974

[seanbudd]

Another example would be "an auto updater" add-on like add-on updater, but just adds the auto update feature to the add-on store.

[lukaszgo1]

I assumed we would go with some more generic approach for #14974 (not necessarily something as complex as proposed in #15073) ,but perhaps just ability to specify add-on store URL in the config. My main problem with what this PR proposes is that the Add-on Store API is... shall we say in not a very good condition. It has been added on top of addonHandler, without clear boundaries between the two. I certainly understand that introduction of the store was a major undertaking for as small org as NV Access, and it is really cool it has happened, It is also clear there were various backwards compatibility and legacy constraints when working on it, but code quality in this part of NVDA is much lower than in the rest of the project. Making the API as it is written now public, means we commit into it, and therefore we would just be adding on top of it indefinitely. I also hope that auto updating of add-ons would be added into the core sooner than later, and for now Add-on Updater does the job without accessing store code at all.

[seanbudd]

@lukaszgo1 - could you perhaps point out any part of the changed add-on store code you think is exceptionally risky to make public? Most of the code in these modules are still private, and the API that is now made available should be relatively stable.

Most of the legacy constraints aren't going anywhere soon, so the complexity of the new code is unlikely to be reduced much in the near future. The reality is we have already pretty much committed to the current API. Very little of the now public API would have changed from 2023.2 to 2024.1, and unless a major rewrite happens after 2024.1, we will just be building on top of it indefinitely.

Even if these particular examples may be integrated into NVDA in the future, there may always be a feature or two that might not be appropriate for core but users want, or the contribution to core comes long after the add-on. It is unusual for NV Access to be overly restrictive of the API like this due to the product vision for customizability. The mark was always going to be temporary. Keeping these entire modules private means we can't easily make parts of the API public in future.