Skip RunAndReturn() on functions with no returns

[skitt]

Description

On functions that don't return anything, RunAndReturn() doesn't call the function given. To avoid misleading users, this changes mockery to not generate RunAndReturn() on such functions; it doesn't seem particularly useful anyway because there's no return value to specify.

Return() is preserved even though it isn't needed either, to avoid confusion with mock.Call.

• Fixes Mock return value provider function does not execute when the function doesn't return anything #506

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

This is technically a breaking change, but it breaks broken code, so on balance it might be better!

Version of Golang used when building/testing:

• 1.22

How Has This Been Tested?

I’ve updated the test suite to account for the expected change.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[LandonTClipp]

Thanks for the PR. I'm not sure I want to just remove this. I feel like it would be better to change the mock so that it actually calls the provided function. From a user's perspective, when I use this function I am expecting the function to be executed, but obviously I wouldn't expect any return value. The proposal here of just removing RunAndReturn would make me upset as I now have to modify all my tests that use this. Instead, I would have preferred mockery to do what I expect in this scenario, which is to run the function.

I know that it will become redundant with .Run but I think I'm okay with that. I'd prefer the mock methods to be consistent rather than strictly orthogonal.