Port solution analysis functionality from matlab

[peterhollender]

Adds the solution analysis functionality from MATLAB.

[peterhollender]

There are still a few TODOs before this can be merged:

1. Remove the previous analysis code, which is largely in openlifu/bf. I can see why we'd want some of these more generic utilities available outside of solution analysis, but I couldn't decide on the best way to structure the code to re-use the code that was already in there. I just stuck all of the methods directly in solution_analysis.py, which made it easy for them to call each other, but that may not be the preferred way
2. Update unit tests
3. There is still a small amount of regression between the MATLAB and Python results, but I've traced it down to seemingly different results using MATLAB k-wave's karray.getDistributedSourceSignal k-wave-python's karray.get_distributed_source_signal. I've been picking through them for a while and can't seem to find any differences in my inputs, so this may be a k-wave issue. It's not that different (the signals look the same, they just are numerically a little different), but it is there.

[ebrahimebrahim]

1. I just stuck all of the methods directly in solution_analysis.py, which made it easy for them to call each other, but that may not be the preferred way

That makes sense. I agree with putting things where it's easiest to use/organize at first, and then if later we want to expose specific things at a higher level then it's not hard to move them.

[ebrahimebrahim]

Oops it looks like you're undoing the things I did in your force-push 😄 ... we'll talk soon anyway

[ebrahimebrahim]

@peterhollender Hey Peter, I am ready to merge this. Please let me know verbally if you approve of it before I go ahead.

I had hoped to get unit tests in last week but I didn't get to it. Now to stay within the timeline of our roadmap, I think I should put off the testing. I indicated in this issue what still needs to be tested. We can go back for this once the april 1 milestone is cleared.

For now I added lots of function documentation to make the unit testing process more straightforward later, and also to not lose the fruits of our discussion on this stuff from last week.

[peterhollender]

@peterhollender Hey Peter, I am ready to merge this. Please let me know verbally if you approve of it before I go ahead.

I had hoped to get unit tests in last week but I didn't get to it. Now to stay within the timeline of our roadmap, I think I should put off the testing. I indicated in this issue what still needs to be tested. We can go back for this once the april 1 milestone is cleared.

For now I added lots of function documentation to make the unit testing process more straightforward later, and also to not lose the fruits of our discussion on this stuff from last week.

Yep, good for me. I'll start working on the table generation code in a separate PR

[ebrahimebrahim]

for other SlicerOpenLIFU developers @sadhana-r @arhowe00 note the rename here from 'ita' to 'intensity' -- it will have to be fixed in SlicerOpenLIFU when the openlifu version is next bumped