Make sure old style references are backwards compatible

[Janpot]

Some properties that used to be represented by a string 'xyz' are now represented by a { $$ref: 'xyz' }. This allows us to detect them in our data structure and treat them as their own datatype. There was no backwards compatibility put in place and we can't do migrations yet, so this will fix older apps that are now broken

[render]

Your Render PR Server URL is https://toolpad-pr-780.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cbqvo21a6gdln1i8cfb0.

[bharatkashyap]

Makes sense

[bytasv]

@Janpot I was wondering - would it make sense to tackle backwards compatibility / migrations problem a little bit more? I mean going forward I assume we will have more and more such cases where we want to tweak data structure. We could open a GH issue and maybe figure out if there is a pattern that we could reuse, or at least start gather info where we needed that so we can build a better picture 🤔

[Janpot]

@bytasv yes, absolutely, it's becoming more and more a blocker as the app gets more complex. Datamodels that we started out with are becoming too simplistic for newer features. There is the following ticket #741
The idea is to version our application datamodel, and provide migrations upwards* for each version. then we'll migrate the model immediately when we load it from the db, so that the application will always work with the latest version and the whole worry about backwards compatibility is contained at a single point. This PR and a few other patches I made before are temporary until we can encode it in a migration.
@bharatkashyap Is starting an effort on that in #776

* We will not tackle down migrations for now as there are no concrete use cases yet. Users must always backup their database before attempting upgrading toolpad. In a farther future where apps are shareable between instances, it may become interesting to support a form of downwards migrations