client: replace submodule with specific release

[alxndrsn]

Closes #1996

What has been done to verify that this works as intended?

• tested locally
• tested in CI
• tested with dev builds (not relevant)
• tested to ensure submodule is not deleted when switching branches

$ git checkout next && git submodule update --init --recursive && ls client && git checkout no-more-submodule && git submodule update --init --recursive && ls client
M	server
Switched to branch 'next'
Your branch is up to date with 'upstream/next'.
Submodule path 'client': checked out '56b6bbdb4cac59aa850e3ddd1cd19ab9f2be1af3'
Submodule path 'server': checked out '142c1c85501d90d225116862ba79dd914c5fcfc1'
bin              docs       icomoon.json  jsconfig.json  LICENSE     NOTICE        package-lock.json  public     SECURITY.md  test       vite.config.js
CONTRIBUTING.md  e2e-tests  index.html    karma.conf.js  nginx-conf  package.json  Procfile           README.md  src          transifex  vue.config.js
warning: unable to rmdir 'client': Directory not empty
M	server
Switched to branch 'no-more-submodule'
Your branch is up to date with 'origin/no-more-submodule'.
Submodule path 'server': checked out 'd36403996af4abca303db4d4e2dbc7b4425f972d'
bin              docs       icomoon.json  jsconfig.json  LICENSE     NOTICE        package-lock.json  public     SECURITY.md  test       vite.config.js
CONTRIBUTING.md  e2e-tests  index.html    karma.conf.js  nginx-conf  package.json  Procfile           README.md  src          transifex  vue.config.js

Why is this the best possible solution? Were any other approaches considered?

• 👍 very fast, low overhead container builds
• 👍 allows local edits
• 👍 doesn't delete local changes in the client/ directory
• 👍 allows arbitrary treeish refs

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

• 👍 should help 3rd-party deployers who don't edit client/central-frontend code
• 👍 should not confuse 3rd-party deployers who do edit client/central-frontend code, although they will need to set a new var in docker-compose.yml when updating

Does this change require updates to documentation? If so, please file an issue here and include the link below.

Yes - deployers who have made edits to client will now need to manage those separately (if they weren't already), e.g.:

--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -3,6 +3,8 @@ services:
     build:
       context: .
       dockerfile: postgres14.dockerfile
+      args:
+        FRONTEND_BUILD_MODE: source
     shm_size: 512m
     volumes:
       - postgres14:/var/lib/odk/postgresql/14

Before submitting this PR, please make sure you have:

• branched off and targeted the next branch OR only changed documentation/infrastructure (master is stable and used in production)
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[lognaturel]

Nothing blocking from me either, just a couple suggestions inline.