Fix alternative platform loading

[alecandido]

The loading mechanism provided in #1123 is convenient for the future. But, unfortunately, to implement it as intended, we should make some more magic to make it work.

Indeed, since we rely on Pydantic for (de)serialization, we need to be pretty specific with the possible types.
However, this is not the case for the InstrumentMap, where we are specifying the parent class, rather than the union of its children.

We already faced this problem for configuration, leading to ConfigKinds, which is not the simplest object.

For the time being, I decided to bypass the problem, since we do not have any actual need to serialize the Hardware object, because our persistence layer for hardware just consists of the platform.py files (which we are reading, but aiming to write automatically).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.69%. Comparing base (b929bac) to head (872373d).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1151      +/-   ##
==========================================
+ Coverage   52.60%   52.69%   +0.09%     
==========================================
  Files          71       71              
  Lines        3173     3177       +4     
==========================================
+ Hits         1669     1674       +5     
+ Misses       1504     1503       -1     

Flag	Coverage Δ
unittests	52.69% <100.00%> (+0.09%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alecandido]

Unfortunately, this part is harder to test, since a platform is required. But I could try to create a dummy-based one, to attempt reproducing the issue.

[alecandido]

Ok, the recursive dumping fully prevents to have actual objects, since they are not loaded back.

So, the Hardware object is now splatted in the load just with shallow dump, which is converting to a dictionary only the outermost level, preserving the inner objects.

[stavros11]

Thanks @alecandido.

Unfortunately, this part is harder to test, since a platform is required. But I could try to create a dummy-based one, to attempt reproducing the issue.

I also tried to reproduce the issue to make sure I understand it correctly and I ended up adding a test in #1153. In any case, we can merge this now since it is a needed fix and discuss the test in the other PR.