优化 eval_frame 对 Paddle 函数的 skip 机制

[SigureMo]

目前我们会在 eval frame 的 callback 入口处检查是否是 Paddle 的函数，如果是则直接跳过，相关逻辑如下：

https://github.com/2742195759/paddle-symbolic-trace/blob/6b77ad2326d74a91e80009699b30aa27137f774d/symbolic_trace/opcode_translator/transform.py#L9

https://github.com/2742195759/paddle-symbolic-trace/blob/6b77ad2326d74a91e80009699b30aa27137f774d/symbolic_trace/opcode_translator/skip_files.py#L93

paddle.nn.Layer.__call__ 这个函数也会被这个规则跳过，而所有继承自 Layer 的网络都会去找到这个 paddle.nn.Layer.__call__ 来作为函数入口，所以我们现在还不支持使用 symbolic_trace 函数直接装饰，需要一些 trick，用函数包装一下，如：

https://github.com/2742195759/paddle-symbolic-trace/blob/6b77ad2326d74a91e80009699b30aa27137f774d/tests/test_17_paddle_layer.py#L18-L19

我们希望优化 Paddle 相关函数的 skip 机制，以支持直接装饰 paddle.nn.Layer

[SigureMo]

@zrr1999 没有标记 good first issue 的有些难度哈，一般是我们还没想到明确的解决方案的

另外这里的描述稍有过时，我同步一个信息：

test_17_paddle_layer 即便不包装也是没问题的，因为即便 paddle.nn.Layer.__call__ 被跳过，其调用的 SimpleNet.forward 仍然会进入 eval frame callback

问题目前主要出在 test_resnet，如果不包装是会有问题的，paddle.nn.Layer.__call__ 及调用的 paddle.vision.ResNet.forward 都会被跳过，因为他们都在 paddle 目录下

目前为什么需要跳过 paddle 下的 API 呢？这是因为 eval frame 编译后的代码里 SIR_x 实际上是一个动转静函数 StaticFunction，里面会有很多动转静相关逻辑，我们是不希望这部分代码进入 eval frame callback 的，因此会对 Paddle API 进行过滤（主要是 paddle.jit.* 以及其内调用的各种 Paddle API），因此换言之我们也许需要一种比较好的机制保证 SIR_x 不会进入 eval frame callback

按照目前的理解生成代码里应该是只有 SIR_x 会错误进入 eval frame callback，其余的应该不会，不过之前也发现了奇怪的现象，仅仅禁用了 StaticFunction.__call__ 部分 eval frame 并不能完全杜绝 eval frame 所带来的开销，不过我们没有测试和查找具体原因，这里仅做信息同步

另外，#100 merge 之后我还没做过相关测试，可能部分信息又过时了

[zrr1999]

@zrr1999 没有标记 good first issue 的有些难度哈，一般是我们还没想到明确的解决方案的

另外这里的描述稍有过时，我同步一个信息：

test_17_paddle_layer 即便不包装也是没问题的，因为即便 paddle.nn.Layer.__call__ 被跳过，其调用的 SimpleNet.forward 仍然会进入 eval frame callback

问题目前主要出在 test_resnet，如果不包装是会有问题的，paddle.nn.Layer.__call__ 及调用的 paddle.vision.ResNet.forward 都会被跳过，因为他们都在 paddle 目录下

目前为什么需要跳过 paddle 下的 API 呢？这是因为 eval frame 编译后的代码里 SIR_x 实际上是一个动转静函数 StaticFunction，里面会有很多动转静相关逻辑，我们是不希望这部分代码进入 eval frame callback 的，因此会对 Paddle API 进行过滤（主要是 paddle.jit.* 以及其内调用的各种 Paddle API），因此换言之我们也许需要一种比较好的机制保证 SIR_x 不会进入 eval frame callback

按照目前的理解生成代码里应该是只有 SIR_x 会错误进入 eval frame callback，其余的应该不会，不过之前也发现了奇怪的现象，仅仅禁用了 StaticFunction.__call__ 部分 eval frame 并不能完全杜绝 eval frame 所带来的开销，不过我们没有测试和查找具体原因，这里仅做信息同步

另外，#100 merge 之后我还没做过相关测试，可能部分信息又过时了

好的，那我最近再多学习一下代码后面再看这个