Remove changeset for publishing

[generall]

This PR proposes to replace changeset publishing process with simple pnpm publish.

There are some reasons:

• changeset have overcomplicated release process, which requires full knowledge of the tool even for simplest operations
• changeset works unpredictably: instead on specifying concrete version number we want to release, changeset forces us to autoincrement versions. This operation is not idempotent and may create problems, for example, during the CI script problems (performing same operation twice does_not guarantee same result)
• Unclear release strategy: same release script, depending on the obscure conditions, may launch a release or create a commit in some other branch (?)

This PR is WIP as publishing CI pipeline was not tested

[changeset-bot]

⚠️ No Changeset found

Latest commit: 85c6458

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rendez]

The release.yml workflow dispatched on tags means anything pushed to master won't run any pipeline, if tags are created off master to issue a release, maybe master should also have a pipeline where we run similar checks as in the pull request workflow, i.e.:

      - name: Project checks
        run: pnpm -r pre-check

      - name: Integration tests
        run: packages/qdrant-js/scripts/integration-tests.sh
        shell: bash

[IvanPleshkov]

The release.yml workflow dispatched on tags means anything pushed to master won't run any pipeline, if tags are created off master to issue a release, maybe master should also have a pipeline where we run similar checks as in the pull request workflow, i.e.:

      - name: Project checks
        run: pnpm -r pre-check

      - name: Integration tests
        run: packages/qdrant-js/scripts/integration-tests.sh
        shell: bash

There are cases when pushing to master should not call any release pipeline. An example of such changes is this PR with CI changes =) We don't want to release something after pushing this PR.
Also, release by tags is comfortable for rust team because of a similar approach for each client (Python, Go, Rust ect). Similar release steps between clients are more comfortable that perfect CI for each client separately.

[IvanPleshkov]

Removed OpenAPI similarity check from CI. There are some cases where we won't check the latest QDrant openapi. This PR is an example of this situation. v1.4.0 is coming but this PR is based on v1.3.0. And we cannot merge this PR. Also, we don't want to merge v1.4.0 first because it will trigger changeset, unresolvable situation.
If someone doubt it, create please separate PR with restoring this check. In such PR grpc protofiles checks are expected too