Implement upgrade suggestions for old MarkBind projects

[jamos-tay]

This is regarding Markbind projects that are missing features because they were created before they were added.

Some features such as layouts add files to the _markbind or assets folder that only get created on markbind init. However, this can cause problems when run with a newer version of markbind with markbind serve.

A few suggestions:

• Automatically upgrade the project: This is the most convenient but may cause the site to display differently unexpectedly
• Detect if the project is outdated, show a warning and request the user run an init command
• Don't upgrade: Disable features that aren't present, which is the current behavior. Requires some maintenance on our side but makes it easier to maintain legacy projects

[damithc]

To minimize this situation, new features can be written with backward compatibility in mind. e.g., if a feature found itself being applied to an outdated site, it can warn the user how to update the code to be compatible with the feature.

[acjh]

1. Automatically upgrade the project: This is the most convenient but may cause the site to display differently unexpectedly
2. Detect if the project is outdated, show a warning and request the user run an init command
3. Don't upgrade: Disable features that aren't present, which is the current behavior. Requires some maintenance on our side but makes it easier to maintain legacy projects

I prefer option 2. Probably with an --upgrade option, or a different command.

To minimize this situation, new features can be written with backward compatibility in mind. e.g., if a feature found itself being applied to an outdated site, it can warn the user how to update the code to be compatible with the feature.

Agreed. New features should not break old projects without warning (or errors) when building the site. This should be flexible enough such that the user can disable some upgrade suggestions. We should probably separate upgrade suggestions from code by implementing this in a separate file (such as upgradeChecker.js) and introducing (e.g. "initVersion" and "optOut") fields in site.json.