Make some elegance/style improvements to the elegance branch

[ronawho]

Some of these might be style preference, and some of them are comments that helped me understand the batching code better. I have no problem sticking with your preferred style if there is something you don't like here. I did not see any noticeable performance difference for the elegant=false code before and after these changes.

Here are the changes I made roughly in the order they appear:

• Added hacky "default intent is ref" to avoid with (ref ....) for plans
• Uppercase Src/Dst since they arrays and the domains were uppercase
• Switch "Dest" to "Dst" so it has the same characters as "Src"
• Made coforall loc in Locales do on loc a single line to lessen indentation
• Cleaned up x,y,z range component declarations
• Rename things like plan_x to xPlan to match xSrc
• Updated elegant to use slice assignment instead of localaccess w/ plan copy
• Added a wrapper offset iterator instead of manually calculating
• Convert things like y0 to ySrc.first, it's cheap to do
• Remove some localAccess calls when calling execute, negligible overhead
• Go to one space after all commas
• Rework performant batching a little to make it more obvious to me what's going on (add some comments, use batchSizeSm/batchSizeLg instead of numTransforms and numTransforms+1)
• Replace remotePut with copy wrapper, and use it to replace memcpy (it'll actually map to a chpl_comm_get, but when local that will be a memmove. We could special case copy to do a memcpy when both are local, but I didn't want to figure out the c_ptr stuff and this shouldn't have any noticeable overhead)

[ronawho]

cc @npadmana

Easiest to review side-by-side ignoring whitespace. If you have changes you're working on, feel free to make me rebase.

[npadmana]

This looks good to me -- I had a few questions/thoughts in the review.

I'm doing some large scale hacking of old, dead code, we can figure out the merge as soon as I'm done.

One question -- I'm actually fine with the {x,y}Plan{Sm,Lg} rewrite. We could certainly hide that behind a BatchedFFTWPlan wrapper, but it feels unnecessary here.

[ronawho]

I'm doing some large scale hacking of old, dead code, we can figure out the merge as soon as I'm done.

Cool!

One question -- I'm actually fine with the {x,y}Plan{Sm,Lg} rewrite. We could certainly hide that behind a BatchedFFTWPlan wrapper, but it feels unnecessary here.

I have a different branch that does that, but I didn't want to jam it into this PR. I was going to open up a separate PR to discuss after this went in. https://github.com/npadmana/DistributedFFT/commit/8da6959610269be1da1e157c9754892bee0cfdce if you want to take a look before that.