Move PostgreSQL adapter into own repo

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Currently, the PostreSQL adapter is an integral part of the Parse Server repo.

This poses several disadvantages:

• Incorrect dependency

  Assuming that the vast majority of Parse Server deployments use MongoDB, the Postgres adapter poses an unnecessary dependency for the majority of Parse Server developers.

• Unclear strategy

  The Postgres adapter does not enjoy the same attention as the MongoDB adapter. One may even assume that it lacks the attention required to recommend it for use in a critical environment. There are currently 67 tests that are excluded from Postgres: 22 it_only_db('mongo'), 30 it_exclude_dbs(['postgres']) , 15 describe_only_db('mongo'). For comparison, there are only 2 it_only_db('postgres') and 5 describe_only_db('postgres').

• Resource inefficiency

  If the vast majority of deployments does not use the Postgres adapter, it seems unjustifiable to invest a lot of resources into it to keep it up-to-date and ensure its fitness for production use.

• Inorganic development

  Excluding the adapter from the server repo allows a more organic development approach that is really at the core of open source. If the adapter finds a critical group of users who maintain it, it will further develop, otherwise it will organically die off and deprecate. For example, the S3 storage adapter is a distinct repo and regularly receives PRs because it is in popular use.

Feature / Enhancement Description

Move the Postgres adapter into its own parse-server-postgres-adapter repo.

Advantages:

• Distinct focus

  The Postgres adapter with its own repo may receive more attention because it has its own issue list and a allows for a more focused discussion.

• Usage metrics

  A separate repo reveals more metrics about its usage and community relevance.

Start by inventorying the PostgreSQL adapter within the Parse Server repository and reviewing the database-specific test exclusions named in the issue. Done means the adapter exists in a separate parse-server-postgres-adapter repository, with its dependencies and integration boundaries defined for Parse Server.