Make good use of delete-free features in release/examples

[bradcray]

This epic relates to getting the release/examples directory to the point that it's using delete-free features as we'd like it from a "best practices" perspective. I believe that in most of the following cases, unmanaged is currently being used simply because it was the most expedient way to get the feature in. A few cases also use new borrowed and should be double-checked.

In some sort of priority-sorted order:

• [x] shootout (binarytrees and chameneosredux*):
  • binarytrees prefers to use unmanaged so it can delete while computing
  • chameneosredux* has been fixed in PR #11010)
• [x] primers (distributions, locales, and learnChapelInYMinutes where this last one uses 'new borrowed')
  • distributions has to use unmanaged due to the current state of things: #10993
  • locales has to use unmanaged due to an open issue with .locale on owned/shared: #10566
  • learnChapel... is improved in #11042
• [x] hpcc (hpl and ptrans)
  • there's not much that can be done with these due to #10993
• [x] users-guide (walkTreeUsingBegins): #11044
• [x] programs (genericStack, linkedList, and tree)
• [x] lcals
• [x] miniMD: #11045
• [ ] ssca2

In the list above, I've skipped primers/classes.chpl, assuming that it's written to use all flavors as part of its teaching of them.

[bradcray]

I've got a start on the shootout and hpcc cases in PR #10945 and will also take on the users guide.

@daviditen : Would you have time to look at LCALS in this sprint?

[daviditen]

Yes, I can take LCALS.

[ronawho]

Close https://github.com/chapel-lang/chapel/issues/10598 in favor of this?

[mppf]

Code that actually wants to manage its own memory should use unmanaged and if that's what the code is doing we should be OK with that. There might be 1 or 2 of the above cases that fall into this category.

[bradcray]

Michael's point is a good one. I don't mean to imply that no codes should ever use unmanaged again, more that we should use what's most appropriate for the code and make sure we're not just using unmanaged because it was the quickest way to keep the program working for this release.

[mppf]

I poked around a bit and don't see anything else that isn't covered above.

[bradcray]

For the 1.18 release, I didn't come up with rewrites of the programs/ files that I was sufficiently happy with to merge (and found myself mostly wondering if that directory should just be removed. It's ancient and doesn't necessarily represent code that we care deeply about.

I essentially timed out on SSCA2, but figured it was a sufficiently large / long-lived code that that didn't feel concerning to me (though I'd like to return to it post-release).

[mppf]

@bradcray - see PR #11086 moving programs