Possible patching bug/maintainability concerns in `test_util.py`

[ChrisKeefe]

Improvement Description
Tests in test_util.py which use mock.patch are wordy, and do not line up nicely with samples from the python docs. Further, they exhibit unusual behavior I haven't yet been able to explain, which raises concerns that they may not be functioning as intended

Current Behavior

    @mock.patch("q2_diversity_lib._util.psutil.Process")
    def test_function_with_an_n_jobs_param(self, mock_process):
        mock_process = psutil.Process()
        mock_process.cpu_affinity = mock.MagicMock(return_value=[0, 1, 2])
        self.assertEqual(self.function_w_n_jobs_param(3), 3)

If we remove mock_process = psutil.Process() from the above snippet, the tests fails, and calls to psutil.Process.cpu_affinity() in the code under test return a mock object instead of returning the assigned return_value=[0, 1, 2]

Proposed Behavior
More succinct and idiomatic testing will improve confidence in test behavior.

Comments

1. If possible, test_system_has_no_cpu_affinity() should continue to operate without using patch's create=true option. (This arg tells patch to create nonexistent attributes). The code is uglier, but the semantics are cleaner if we let tests run on macOS trigger create AttributeErrors "naturally" than if we patch in an artificial cpu_affinity method which yields a patched AttributeError.

References

1. Discussion/docs link in this comment
2. Attempts to remedy in this PR
3. Further notes