Lazy load AudioDevice properties, add additional functions

[timtucker]

Made a few tweaks:

• Changed to lazy load AudioDevice properties -- this should be a little faster in cases where the properties otherwise go unused and helps get around some of the issues with exceptions being thrown when accessing the properties on system devices
• Updated associated tests for CreateDevice to include manually accessing the properties -- with the update to lazy load, one of the tests failed as-is because it was expecting a failure that was no longer thrown until you manually access properties
• Added a few functions to make it easier to enumerate things & access properties -- as an example, AudioDevice now has a Sessions property that can be used to access the list of sessions for the device
• Did some refactoring to move duplicate code into helper functions
• Tried to make variable names more consistent in spots where the same type of object was being referred to with different names
• Added typing in multiple spots for better IDE auto-completion

Note that in every case where I could I kept the behavior the same.

Changed behavior from the current release:

Getting session by process id. This now looks at all sessions, regardless of which device they're associated with.

Not changed, but probably should change:

"GetAllSessions" -- it doesn't actually return "all" sessions. It just returns sessions associated with the default playback device.

A few of the areas where that might not be all:

• Recording-only sessions
• Windows configured to output sounds for different applications to different devices
• Windows configured to have different output devices as the default for playback vs. communications

[timtucker]

Thanks for the refactoring, the main idea is good, the refactoring makes sense and the lazy loading is a nice addition. The pull request is a bit too big for my taste, I like to break down into smaller pull requests when possible so it's easier to keep focus when reviewing and easier to git bisect it when there's a regression. Also small PRs get less comments and get merged faster. Thanks for bringing some type hints, I like them too, in the future we would need to lint them to make sure they're not lies, but let's keep it for another PR.

Agreed that this is definitely a lot -- I started working on a small project locally and started doing some late-night tinkering and just figured I'd upload what I had done so far.

IMO, part of the issue is that there's too much in utils right now.

Changes might be easier to keep narrower in scope if it were split up something like:

audio\device.py

• class to interact with a specific device
• instances could cache for device properties or interfaces that are unlikely to change

audio\session.py

• class to interact with a specific session
• instances could cache of session properties or interfaces that are unlikely to change

audio\controllers.py

• class to list & interact with devices, with caching of previously seen devices
• class to list & interact with sessions, with caching of previously seen sessions
• default instances of the session & device controllers that are aware of one another
• Example usage would just be: from pycaw.audio.controllers import audio_sessions, audio_devices

audio\types.py

• type definitions to avoid circular imports

utils.py

• stubs that use the default controllers + new interfaces for backward compatibility

[AndreMiras]

Yes you're right that this should be split like you said. Let's keep this for a follow up PR, because I don't want to move things around too much and it would be harder to track the rest of the changes.