Enable creation of nodes from dictionary

[InnocentBug]

@brili please check if that is along the lines of what you had in mind.

Tests are passing on my end.
(I also see that @izaim added a branch for CI tests here, probably coming soon.)

I am skipping CriptNode.final_update if the node is not initialized.

I added a test that uses Materials from a search, which get successfully converted to nodes.
We may want to try other types of classes too.

I am open to making the new private functions.

1. CriptNode._from_dict
2. CriptNode._cls_from_dict

public. I would like to know what you think for the design and user experience.

@Ardi028 for visibility.

[InnocentBug]

I will merge this into #6 once approved. Keeping the PRs small to handle.

[InnocentBug]

Questions for @brili while I went through this one.

Is there a specific reason why we inherit from built-in dict instead of collections.UserDict?
And related, what is the reason that we don't call super() on the parent dict in CriptNode.__init__?
Is that how we make sure certain attributes are ignored?

[brili]

you need to assign valid kwargs to self at this point and then return

[InnocentBug]

Did I do it right now?

[brili]

yes but we need to make sure not to include the extra fields that the api returns, you can refactor the retrieve_by_uuid and create a separate method from

allowed_data = {}
for key in data:
    if key in self.__dict__["schema"]["$defs"][f"{self.__class__.__name__}Post"]["properties"]:
        setattr(self, key, data[key])
        allowed_data[key] = data[key]
self.__dict__["__original__"] = copy.deepcopy(allowed_data)

[InnocentBug]

Thanks for the pointers.
I used that snippet to refactor it a little bit.

I think there is some room to streamline this a little bit.
But we can address that in a refactor down the line.