Migrate from rules_nodejs to rules_js/rules_ts (take 2) (#7928)

* Migrate from rules_nodejs to rules_js/rules_ts (take 2)

This is the second version of patch #7923. The first version got
reverted because bazel query was failing:

    $ bazel --nosystem_rc --nohome_rc query tests(set('//...')) except tests(attr("tags", "manual", set('//...')))
    ERROR: Traceback (most recent call last):
    	File "/workdir/tests/ts/bazel_repository_test_dir/BUILD", line 6, column 22, in <toplevel>
    		npm_link_all_packages(name = "node_modules")
    	File "/var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/ec321eb2cc2d0f8f91b676b6d4c66c29/external/npm/defs.bzl", line 188, column 13, in npm_link_all_packages
    		fail(msg)
    Error in fail: The npm_link_all_packages() macro loaded from @npm//:defs.bzl and called in bazel package 'tests/ts/bazel_repository_test_dir' may only be called in bazel packages that correspond to the pnpm root package '' and pnpm workspace projects ''

This was happening because the `.bazelrc` file only added
`--deleted_packages` to the `build` command. We also need it for the
`query` command. This second version of the patch fixes that.

Original commit message:

This patch migrates the current use of rules_nodejs to the new rules_js.
rules_js is the intended replacement of rules_nodejs as per this note:
https://github.com/aspect-build/rules_js#relationship-to-rules_nodejs

> rules_js is an alternative to the build_bazel_rules_nodejs Bazel module
> and accompanying npm packages hosted in
> https://github.com/bazelbuild/rules_nodejs, which is now
> unmaintained. All users are recommended to use rules_js instead.

There are a few notable changes in this patch:
1. The `flatbuffer_ts_library` macro no longer accepts a `package_name`
   attribute. This is because rules_js appears to manage the import
   naming of dependencies via top-level `npm_link_package` targets.
   Users will have to migrate.
2. I added a few more arguments to `flatbuffer_library_public()`. These
   helped with exposing esbuild to `ts/compile_flat_file.sh`.
3. I pinned the version of `typescript` in `package.json` so that
   rules_ts can download the exact same version. rules_ts doesn't know
   what to do if the version isn't exact.
4. Since rules_js uses the pnpm locking mechanism, we now have a
   `pnpm-lock.yaml` file instead of a yarn lock file.
4. I added bazel targets for a few of the existing tests in `tests/ts`.
   They can be run with `bazel test //test/ts:all`. Since there is no
   flexbuffers bazel target, I did not add a bazel target for the
   corresponding test.
5. I added a separate workspace in `tests/ts/bazel_repository_test_dir/`
   to validate that the flatbuffers code can be imported as an external
   repository. You can run the test with
   `bazel test //test/ts:bazel_repository_test`. For this to work, I
   needed to expose a non-trivial chunk of the flatbuffers code to the
   test. I achieved this through some recursive `distribution`
   filegroups. This is inspired by rules_python's workspace tests.

I did not do anything special to validate that the `gen_reflections`
parameter works the same. This patch doesn't change anything about
the TypeScript generation.

As a side note: I am not an expert with rules_js. This patch is my
attempt based on my limited understanding of the rule set.

Fixes #7817

* Fix the query

---------

Co-authored-by: Derek Bailey <derekbailey@google.com>

tests/ts/BUILD.bazel

@@ -1,3 +1,4 @@
+load("@aspect_rules_js//js:defs.bzl", "js_test")
 load("//:typescript.bzl", "flatbuffer_ts_library")
 
 package(default_visibility = ["//visibility:private"])
@@ -10,3 +11,68 @@ flatbuffer_ts_library(
         "//tests/ts/test_dir:typescript_transitive_ts_fbs",
     ],
 )
+
+TEST_DATA = glob([
+    "my-game/*.js",
+    "my-game/example/*.js",
+    "my-game/example2/*.js",
+])
+
+TEST_UNION_VECTOR_DATA = glob([
+    "union_vector/*.js",
+])
+
+TEST_COMPLEX_ARRAYS_DATA = glob([
+    "arrays_test_complex/**/*.js",
+])
+
+# Here we're running the tests against the checked-in generated files. These
+# are kept up-to-date with a CI-based mechanism. The intent of running these
+# tests here via bazel is not to validate that they're up-to-date. Instead, we
+# just want to make it easy to run these tests while making other changes. For
+# example, this is useful when making changes to the rules_js setup to validate
+# that the basic infrastructure is still working.
+[js_test(
+    name = "%s_test" % test,
+    chdir = package_name(),
+    data = data + [
+        "package.json",
+        "//:node_modules/flatbuffers",
+        "//tests:test_data_copied_to_bin",
+    ],
+    entry_point = "%s.js" % test,
+) for test, data in (
+    ("JavaScriptTest", TEST_DATA),
+    ("JavaScriptUnionVectorTest", TEST_UNION_VECTOR_DATA),
+    # TODO(philsc): Figure out how to run this test with flexbuffers available.
+    # At the moment the flexbuffer library is not exposed as a bazel target.
+    #("JavaScriptFlexBuffersTest", TBD_DATA)
+    ("JavaScriptComplexArraysTest", TEST_COMPLEX_ARRAYS_DATA),
+)]
+
+sh_test(
+    name = "bazel_repository_test",
+    srcs = ["bazel_repository_test.sh"],
+    data = [
+        "//:distribution",
+        "@bazel_linux_x86_64//file",
+    ] + glob(
+        [
+            "bazel_repository_test_dir/**/*",
+        ],
+        exclude = [
+            "bazel_repository_test_dir/bazel-*/**",
+        ],
+    ),
+    tags = [
+        # Since we have bazel downloading external repositories inside this
+        # test, we need to give it access to the internet.
+        "requires-network",
+    ],
+    # We only have x86_64 Linux bazel exposed so restrict the test to that.
+    target_compatible_with = [
+        "@platforms//cpu:x86_64",
+        "@platforms//os:linux",
+    ],
+    deps = ["@bazel_tools//tools/bash/runfiles"],
+)