Add a universal aspect_bazel_lib dependency for csharp and nodejs rules

[farost]

What is the goal of this PR?

typedb-driver and typedb-protocol builds have been broken after a recent ts rules update because of the updated aspect_bazel_lib dependency.

To fix the current issue and prevent its reproduction, we add a universal aspect_bazel_lib dependency with a specific version, which is maximal for all the dependent rules in dependencies. This dependency should be explicitly declared before using any rule that depends on aspect_bazel_lib of any version and updated every time a rule uses a newer version of it as its dependency.

What are the changes implemented in this PR?

We add a universal aspect_bazel_lib macro with a single http_archive call for this dependency. We also add invocations of this macro for all the rules' dependencies that depend on aspect_bazel_lib. It lets us not worry about the relative order of these rules declarations in WORKSPACEs as only the aspect_bazel_lib()'s version will be used for all these rules.

The fix works because Bazel uses the first declaration of a dependency. This way, if we have multiple http_archives of aspect_bazel_lib, only the first one is used for every rule depending on it.

It can be a problem if this common dependency becomes not backward-compatible and we cannot make all of our dependent rules use a single version. However, everything is fine while it works.

A similar approach can be used for any other common dependency if we face such issues in the future.

An example of a fixed build for protocol

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [x] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.