Repository: pytorch
Issue: Unnecessary python bindings and documentation for internal functions/ops
Labels: triaged,module: codegen

## 🐛 Bug
Functions/ops with leading underscores (meant for internal use) are being exposed to the public API in `PyTorch`.
This may not qualify as a bug but is also probably not intended.

It might be because of how PyTorch codegen generates python code for all the function listings in`native_functions.yaml`.
It is perhaps useful to skip the generation of Python bindings for such private internal functions (eg. `torch._cat` should not be available, it exists currently for no reason to the best of my knowledge), which may take unnecessary time and resources when building.

## To Reproduce

This is just one of the many private functions which are exposed to the Python API, which are really not needed.
```python
import torch
a = torch.arange(2)
b = torch.arange(2)
torch._cat([a, b])
```

<hr/>

### Documentation
I also have a documentation concern here.

#### `libtorch` doc is not clear with public and private API:
In fact, these `_cat` like methods are documented in the `libtorch` docs. Take the [example](https://pytorch.org/cppdocs/search.html?q=cat&check_keywords=yes&area=default) of searching `cat` documentation on `libtorch`. It clearly shows a lot of internal functions like `at::_cat` etc.

#### `pytorch` doc is perfectly fine:
The good part for `PyTorch` (python API) is that at least these private functions are not documented, so there is no confusion.

So in the long run, as `libtorch` gains a wider user base, these private functions in the public docs can become a pain.
For example, take the case if/when PyTorch developers need to move/remove some internal function. As a developer/contributor, we don't guarantee the maintenance/BC of private API (we should be able to make changes to those internal functions overnight if needed, for whatever reason, without any warnings to users as long as the public-facing API is still the same). But if they are exposed in docs (without any mention of public/private API) then people might as well start using those and then moving/removing them will be a cause of complaints from `libtorch` users.

In short, the public API is not very clear in `libtorch` docs at least to me.

<hr/>

## Expected behaviour

#### Remove unused python bindings
As suggested by @Lezcano (offline discussion) It would be interesting to make it just generate python code for those that do not have a leading underscore or in general are not part of the public API.

Note: Pointed out by @IvanYashchuk (offline discussion), what python functions are generated can be controlled in [`should_generate_py_binding`](https://github.com/pytorch/pytorch/blob/6f95850127e4659f857116c8205f03f66ab5a711/tools/autograd/gen_python_functions.py#L115) function.

#### Remove private funcs / Add warning to private funcs in libtorch docs
Would it be a nice idea if these generated docs mention a note with leading `_` functions being private API? Or would be better to completely skip their documentation somehow?

## Environment

```
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: macOS 11.4 (x86_64)
GCC version: Could not collect
Clang version: 12.0.5 (clang-1205.0.22.11)
CMake version: version 3.19.5
Libc version: N/A

Python version: 3.8.10 (default, May 19 2021, 11:01:55)  [Clang 10.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] numpydoc==1.1.0
[pip3] torch==1.8.1
[pip3] torchvision==0.9.1
[conda] numpy                     1.20.3                   pypi_0    pypi
[conda] numpydoc                  1.1.0                    pypi_0    pypi
[conda] torch                     1.8.1                    pypi_0    pypi
[conda] torchvision               0.9.1                    pypi_0    pypi
```

cc @Lezcano @IvanYashchuk @ezyang