Introduce new package spec version

[jlind23]

Introduce package spec format version example format_version: '1.0'

Per discussed during one of our team weekly, we will upgrade the package spec version as It is almost impossible to add control over package spec.

Most of the time it breaks a lot of packages and will imply bulk changes a the same time.

Changes packages spec will help us be more strict on validation for new incoming packages, leave older packages as is, add new types and fields without impacting packages without format_version.

Related:
#313
#338
#281

[jsoriano]

At the moment I think we have three main options to complete this task:

1. Create v2 as a copy of v1, and maintain both copies. This option has the advantage of being the easiest one, and follows the current approach in the repository with the versions directory. It has the disadvantage of needing to keep several copies of the spec, and we may need to sync bugfixes between them. This is the approach implemented in Introduce format version v2 #380.
   1. An alternative to this would be to create one branch per major, and implement an entry point library that chooses the branch to use.
2. Focus by now only on semantic validation, that is the current blocker for the breaking validations we want to add. This would be also relatively easy and would unblock other tasks, but wouldn't give a solution for schema files. This is the approach implemented in Introduce initial version 2 and stronger versioning support for the spec #384.
3. Use a more expressive schema definition language. This could be a longer-term solution with more advantages, would also solve Consider alternatives to jsonschema for validation #287. The disadvantage is that is a bigger effort, and we would still need something like option 2 for semantic validation that cannot be represented in the new language.
   A POC for schema validation using CUE language is explored in https://github.com/jsoriano/cuetest.

Long-term option 3 looks like the best option.