New pseudo-keys: Part I

[bpoldrack]

Sits on top of PR #707 and resolves its issue WRT is_asset_directory by removing that key altogether. This is now split into the new onyo.is.asset and onyo.is.directory pseudo-keys. Although for the most part onyo.is.directory is what is used instead.

This is the first PR of a series, aiming to implement #662, #688, #689. It's introducing an Item class and a new PSEUDO_KEYS mapping, that add pseudo-keys to dict-likes. The aim for this PR is:

• Make path and directory keys aliases and replace their internal usage (except for test code, where they are still used at times in their role as default aliases)
• Remove is_asset_directory key in favor of onyo.is.directory (and onyo.is.asset)
• Replace DotNotationWrapper by Item in most places. DotNotationWrapper remains valid in some places where we don't want any pseudo-keys yet (For example: Reading yaml from an edited temporary file - only becomes an Item when we tie it to the actual repo. We don't want pseudo-keys referring to the temp file)
• Don't break anything other than is_asset_directory while throwing this class in.
• It does not yet utilize Item's ability to represent directories, templates, etc. - just assets in the first round.
• It does not yet implement git metadata keys, but builds on a mechanic that is meant to account for the need to lazy load pseudo-keys.
• It does not yet introduce a proper mechanic for namespaces nor streamline the usage of this class yet. I want to see what this really needs first.

The scope is limited, in order to address that topic in digestable chunks. Next up should be:

• git metadata
• actually use Item consistently for anything at high-level code, so this becomes the datastructure, that Inventory and command implementations deal with, instead of arbitrary dicts and paths.
• Build different validators (at least in terms of design). Anything is an Item, but what it's used for is what makes the difference. If I want to use an asset as a template, I simply treat it that way (and put it into a TemplateValidator). As opposed to the initial idea of the object itself determining what it is. There may be more to do in a similar fashion along this line of thought.
• consequently properly implement namespaces and allow get to query anything (dirs, templates)

During these further steps, we/I can figure out additional functions to ease various ways of dealing with these objects (we need to repeatedly strip or reset pseudo-keys and we have notions of "you-can't-set-these", leading to a bunch of code duplication - I want to iron that out as we get to see more access patterns)

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 95.93023% with 14 lines in your changes missing coverage. Please review.

Project coverage is 94.60%. Comparing base (b8a415b) to head (402b7c7). Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
onyo/tests/benchmark.py	0.00%	4 Missing :warning:
onyo/lib/commands.py	86.36%	1 Missing and 2 partials :warning:
onyo/conftest.py	71.42%	1 Missing and 1 partial :warning:
onyo/lib/differs.py	0.00%	2 Missing :warning:
onyo/lib/items.py	97.22%	1 Missing and 1 partial :warning:
onyo/lib/inventory.py	95.65%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #735 +/- ## ========================================== - Coverage 96.38% 94.60% -1.78% ========================================== Files 69 73 +4 Lines 6113 6395 +282 Branches 526 542 +16 ========================================== + Hits 5892 6050 +158 - Misses 132 252 +120 - Partials 89 93 +4 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests