Refactor helper methods: utils class vs command classes

Discussed in https://github.com/pnp/cli-microsoft365/discussions/2979

<div type='discussions-op-text'>

^{Originally posted by appieschot January 25, 2022} Discussion started here: https://github.com/pnp/cli-microsoft365/pull/2918#issuecomment-1019300287

We currently have some base methods that provide helper functionality in that base class. We also use the getAppObjectId in the m365 aad app commands. We could pick to have a an abstracted AppCommand class so we can have 1 implementation instead of the multitude we have now (used in app-get, app-role-add, app-role-delete, app-role-list and app-set commands (as well as this one but this might be a bit of an odd duck as this in the future should inherit from whatever we decide in #2961.

Yet discussing that @waldekmastykarz pointed out it makes more sense to revisit and refactor or extend our Utils and provide (grouped) helper methods there. It feels like we should design both how our Utils should work and to research what we could move there for a V1. </div>

• identify how to break up utils from the global Utils class but also service-specific utils
• agree on new structure
• refactor code

[waldekmastykarz]

WIP: https://github.com/waldekmastykarz/cli-microsoft365/tree/utils-modules

The Utils class is no more and all methods are split into functions divided over multiple modules. Code compiles, but there are still some broken tests. I got rid of a few base classes but still need to do another pass. Last part left will be the removal of ItemsListCommand with the special getAllItems method which is now a part of the odata utils.

[garrytrinder]

In favour 👍