This PR canonicalizes our (current) pattern for adding aliases to PyTorch. That pattern is:

• Copy the original functions native_functions.yaml entry, but replace the original function's name with their own.
• Implement the corresponding functions and have them redispatch to the original function.
• Add docstrings to the new functions that reference the original function.
• Update the alias_map in torch/csrc/jit/passes/normalize_ops.cpp.
• Update the op_alias_mappings in torch/testing/_internal/jit_utils.py.
• Add a test validating the alias's behavior is the same as the original function's.

An alternative pattern would be to use Python and C++ language features to alias ops directly. For example in Python:

torch.absolute = torch.abs

Let the pattern in this PR be the "native function" pattern, and the alternative pattern be the "language pattern." There are pros/cons to both approaches:

Pros of the "Language Pattern"

• torch.absolute is torch.abs.
• no (or very little) overhead for calling the alias.
• no native_functions.yaml redundancy or possibility of "drift" between the original function's entries and the alias's.

Cons of the "Language Pattern"

• requires manually adding doc entries
• requires updating Python alias and C++ alias lists
• requires hand writing alias methods on Tensor (technically this should require a C++ test to validate)
• no single list of all PyTorch ops -- have to check native_functions.yaml and one of the separate alias lists

Pros of the "Native Function" pattern

• alias declarations stay in native_functions.yaml
• doc entries are written as normal

Cons of the "Native Function" pattern

• aliases redispatch to the original functions
• torch.absolute is not torch.abs (requires writing test to validate behavior)
• possibility of drift between original's and alias's native_functions.yaml entries

While either approach is reasonable, I suggest the "native function" pattern since it preserves "native_functions.yaml" as a source of truth and minimizes the number of alias lists that need to be maintained. In the future, entries in native_functions.yaml may support an "alias" argument and replace whatever pattern we choose now.

Ops that are likely to use aliasing are:

• div (divide, true_divide)
• mul (multiply)
• bucketize (digitize)
• cat (concatenate)
• clamp (clip)
• conj (conjugate)
• rad2deg (degrees)
• trunc (fix)
• neg (negative)
• deg2rad (radians)
• round (rint)
• acos (arccos)
• acosh (arcosh)
• asin (arcsin)
• asinh (arcsinh)
• atan (arctan)
• atan2 (arctan2)
• atanh (arctanh)
• bartlett_window (bartlett)
• hamming_window (hamming)
• hann_window (hanning)
• bitwise_not (invert)
• gt (greater)
• ge (greater_equal)
• lt (less)
• le (less_equal)
• ne (not_equal)
• ger (outer)