Add Op(built-in function ops) | feat(torchlib)

[titaiwangms]

Fix https://github.com/microsoft/onnx-converters-private/issues/190

With pytorch/pytorch#112758, this PR moves built-in function ops mapping into torchlib.
NOTE: module name of operator.add is _operator

[codecov]

Codecov Report

Merging #1135 (29e8bb5) into main (b0147d8) will decrease coverage by 0.02%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##             main    #1135      +/-   ##
==========================================
- Coverage   78.40%   78.39%   -0.02%     
==========================================
  Files         118      118              
  Lines       15046    15054       +8     
  Branches     1604     1604              
==========================================
+ Hits        11797    11801       +4     
- Misses       2878     2882       +4     
  Partials      371      371              

Files	Coverage Δ
onnxscript/function_libs/torch_lib/ops/core.py	79.73% <80.00%> (-0.08%)	⬇️

[justinchuby]

LGTM. Cc @BowenBao for namespace naming conventions

[justinchuby]

I am thinking something like python.operator and python.math may be more principled

[titaiwangms]

I am thinking something like python.operator and python.math may be more principled

A different domain from DOMAIN = "pkg.onnxscript.torch_lib"? I don't know if we should mark the difference in the graph, as they are the same (eg: operator.add and aten::add) in ONNX perspective.

[justinchuby]

I meant python.operator::add or python.math::div to denote they are python built-in values and avoid potential name conflicts (although unlikely)

[titaiwangms]

I meant python.operator::add or python.math::div to denote they are python built-in values and avoid potential name conflicts (although unlikely)

In that case, string processing would need to live somewhere in torchlib registration or converter registration to match _operator.add (original name).

[justinchuby]

SG. That's a good argument to keep the existing names