[llvm] [libc][bazel] Add bazel targets for libc/include/... tests. (PR #141150)

[via llvm-commits]

================
@@ -71,6 +71,7 @@ libc_test_library(
         "//libc:llvm_libc_macros_stdfix_macros",
         "//llvm:Support",
     ],
+    alwayslink = True,
----------------
jtstogel wrote:

> So, both with and without this change the link would fail with duplicate symbol: main if the unit test which has its own `main()` would depend on `//libc/test/UnitTest:LibcUnitTest`.

I could be misconfigured on my machine, but AFAICT this isn't true?

Here's some code examples: https://github.com/llvm/llvm-project/compare/main...jtstogel:llvm-project:linker-opt-example. My understanding (which may be incorrect) is that the linker won't include the object file unless a symbol is used, so if the test has it's own `main()`, the unit test framework main will just be ignored.

> E.g. if a unit test accidentally has its int main() wrapped in a namespace, then both with and without this change the test will instead pick up the main() from the framework, won't it?

Sorry that example wasn't well formed. I think a better argument for why files like these should set `alwayslink=True` is that the program's semantics falls down to link order. In the following example, what does the test do? I would expect it to immediately fail with `duplicate symbol: main`, but on my machine the test either fails or passes based on the ordering of `[":main1", ":main2"]`.

```
cc_test(
  name = "example_test",
  srcs = ["example_test.cc"],
  deps = [":main1", ":main2"]
)

cc_library(name = "main1", srcs = ["main1.cc"])

cc_library(name = "main2", srcs = ["main2.cc"])
```

main1.cc
```
int main(void) { return 1; }
```

main2.cc
```
int main(void) { return 0; }
```

example_test.cc
```
// empty
```

https://github.com/llvm/llvm-project/pull/141150