Proper build() methods for TF
Author: Rocketknight1
Pull request: yes

TensorFlow builds weights **lazily**. This means that layers do not have an `input_dim` argument and do not create weight tensors in the model `__init__()`. Instead, the layers wait until their `build()` method is called, which usually happens implicitly the first time the layer receives an input. Layers use the shape of the first input they see, or the value explicitly passed to their `build()` method, to infer their input dim and build their weight tensors.

Up until now, almost none of our TF models had explicit `build()` methods. This meant that weights were built implicitly when the model was called, which required lots of tiny hacks all over the codebase:

- We had to do an entire forward pass *inside `from_pretrained()`* to prepare the model weights so that we could load a checkpoint
- We had to be careful about call stacks and name scopes to ensure that models did not accidentally build themselves inside an existing call/name context and destroy their weight names. This meant our code had to sniff the existing TF call stack, which (among many other issues) completely breaks Keras 3.
- Several models had explicit calls to `tf.name_scope()` inside their forward pass (!) to control their weight names, which only worked because the weights were always built there

This had always been a big chunk of tech debt that I'd wanted to fix, but it was such a large task that I never really had time. However, with Keras 3 approaching, it became quite urgent. I tried getting GPT-4 to figure out the `build()` shapes automatically, but it generally failed, so I had to resort to using `ast` and static analysis of the PyTorch and TF modeling files to cross-match layers from TF to PyTorch code, using the input size arguments from PyTorch to automatically create and populate new `build()` methods, and then did a manual pass afterwards to fix up the remaining issues.

As a result, after this PR:

- All models now have correct `build()` methods
- Weight names are correct even if models are called weirdly, because we can now tightly control the `build()` hierarchy
- Probably the single biggest source of TF bugs we had is gone
- No more forward passes when building models, including with `from_pretrained()`! Should make model loading significantly faster, especially on CPU, and should help in the CI.
- A major Keras 3 blocker is removed.

While I was working on this PR, I also encountered some other issues that I fixed in passing:
- Added a `build_in_name_scope()` method and refactored some tests/methods to use it instead. Calling this method yields the same name hierarchy as implicitly calling `build()` when doing a forward pass, whereas directly calling `model.build()` does not (because TF enters a name_scope in `__call__()`)
- Updated TFAdaptivePool2D for Data2Vec, should massively improve model performance
- Fixed some details in the `TFSequenceSummary` and `TFConv1D` classes. These are mostly used by older models.

**Note to reviewers:** Most of this PR was generated automatically, and just consists of walls of new `build()` methods. You can generally trust that these methods are correct so long as the CI is green, so you hopefully don't have to read them all - there's >11,000 lines of them! The main things to review are the changes in core files like `modeling_tf_utils.py`, the new `build_in_name_scope()` method, etc.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_27794). All of your documentation changes will be reflected on that endpoint.

oh my god the tests pass i didn't think this was ever going to happen

Thanks! There's one thing left to add - some layers are buildable with int shapes in Keras 2, but that always fails in Keras 3. I'm going to do a quick replacement so that those become actual shapes (with extra `None` dimensions) - it should have no impact on Keras 2 either way.

Quick update: The build shapes all have proper ranks instead of just being ints now, but our old method of controlling names with `tf.name_scope()` isn't working for Keras 3 - I've asked Chollet what the recommended solution there is

Got a solution, but I think it fits better in another PR! I'm gonna merge this one for now and see what shakes out in the nightly CI, while I work on the next phase of Keras 3 compatibility.

Not sure I get why this was merged?