Fix leaks in gui_helper_3_helper_.

[1uc]

The facts are:

• PyTuple_SetItem steals its third argument 1.
• hocobj_new returns a new reference.
• cpp2refstr returns a new reference.

In both cases the reason it leaks is that hocobj_new or cpp2refstr creates a new reference, then the reference count is increased once more. The one reference is stolen by PyTuple_SetItem; but there's still one INCREF which we can't pair up with a DECREF.

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[azure-pipelines]

✔️ e68cc45 -> Azure artifacts URL

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 67.09%. Comparing base (5f0675b) to head (e68cc45).

Files with missing lines	Patch %	Lines
src/nrnpython/nrnpy_hoc.cpp	0.00%	5 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3256   +/-   ##
=======================================
  Coverage   67.09%   67.09%           
=======================================
  Files         570      570           
  Lines      111082   111081    -1     
=======================================
  Hits        74525    74525           
+ Misses      36557    36556    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bbpbuildbot]

Logfiles from GitLab pipeline #239424 (:no_entry:) have been uploaded here!

Status and direct links:

• ✅ mac_m1_cmake_build: [cmake, ON, OFF, OFF, address]
• ✅ spack_setup
• ✅ build:nmodl
• ✅ build:neuron:nmodl:intel:legacy
• ✅ build:neuron:nmodl:intel:shared
• ✅ build:neuron:nmodl:nvhpc:acc:legacy
• ✅ build:neuron:nmodl:nvhpc:acc:shared
• ✅ build:neuron:nmodl:nvhpc:omp:legacy
• ✅ build:neuron:nmodl:nvhpc:omp
• ✅ test:neuron:nmodl:intel:legacy
• ✅ test:neuron:nmodl:intel:shared
• ✅ test:neuron:nmodl:nvhpc:acc:legacy
• ⛔ test:neuron:nmodl:nvhpc:acc:shared
• ✅ test:neuron:nmodl:nvhpc:omp:legacy
• ✅ test:neuron:nmodl:nvhpc:omp

[1uc]

@nrnhines The issue is that because we do manual reference counting, the following entirely made up sequence of steps might be possible:

1. We create a tuple with an element whose reference count is too high by one.
2. We know that the tuple will be passed to the GUI layer.
3. We know that the GUI layer steals the element from the tuple, which explains why the element has an inflated reference count.

Or it's just a leak that can be fixed as proposed in this PR. However, since it's GUI related it's likely not covered by the tests, which is why I'd like to ask you if you think merging this PR is a good idea.