Handle native location query for NAR operators

[FedericoNegri]

Workaround to the fact that NAR operators are exposed as mapdl::rst::<operator-name> (e.g. mapdl::rst::NS) but the operator name in the result info only includes <operator-name> (e.g. NS). These changes allow to query the native location of say mapdl::rst::NS.

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.12%. Comparing base (771f72b) to head (6e2a986).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #924      +/-   ##
==========================================
+ Coverage   85.11%   85.12%   +0.01%     
==========================================
  Files          52       52              
  Lines        5220     5224       +4     
==========================================
+ Hits         4443     4447       +4     
  Misses        777      777              

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[PProfizi]

Hi @FedericoNegri just so I understand, why do we need to deal with mapdl::rst::NS in a specific way? Why not go through NS? When is mapdl::rst::NS called explicitly? Is it a workaround for your project?

[FedericoNegri]

As in the description: those results report for example NS as operator name, but NS is not exposed, only mapdl::rst::NS is. So we use mapdl::rst::NS in result workflows, but would then fail to query the native location.