fix: fix the prim::Loop fallback issue

[bowang007]

Description

In current fallback logic, prim::Loop is set to be run in Torch firstly by this line:

if (!conversion::OpSupported(n)) {
      // If the op is not supported by the conversion phase it should run in PyTorch
      ctx->setNodeExecutorDecision(n, NodeExecutorDecision::kUNSUPPORTED);

However, in segmentation part, there is a contradiction:

else if (n->kind() == torch::jit::prim::Loop) {
        if (!in_prog_pyt_blk_nodes.empty()) {
          finalizeNewBlock(segmented_blocks, SegmentedBlock::kTorch, in_prog_pyt_blk_nodes);
          cur_pyt_nodes_uses.clear();
        }
        if (checkLoopEvaluatable(n)) {
          in_prog_trt_blk_nodes.push_back(n);
          cur_trt_nodes_uses.insert(dependent_nodes.begin(), dependent_nodes.end());
        } else {
          auto loop_node = std::vector<torch::jit::Node*>{n};
          finalizeNewBlock(segmented_blocks, SegmentedBlock::kTorch, loop_node);
          segmented_blocks.back().do_not_merge(true);
        }
        continue;
      }

This introduces many issues and bugs that we have now.
The reason is that firstly setting LOOP running in Torch will make many nodes that produce values consumed in this LOOP block or nodes that consume the values dependent in this Block fallback.
In other words, setNonTensorConnectedNodes won't work as what we expected, and this would introduce a lot of NonTensor Input TensorRT segment after segmentation.

Fixes #1617

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines

[gs-olive]

Update checkLoopEvaluatable to checkLoopEvaluatable(n)

[gs-olive]

PR (with the fix suggested in the review) passes core test cases and resolves same model failures as PR #1617 - after the suggested changes, it looks good to me. A minor note would be to evaluate whether something similar is needed for prim::If, or if the conditional case should not be handled in this way.

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[gs-olive]

Looks good to me (see comment above as well - #1691 (comment))

[narendasan]

LGTM pending tests

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines

[github-actions]

Code conforms to C++ style guidelines

[github-actions]

Code conforms to Python style guidelines