Add metadata info into DDL

[no1seman]

As for now different tarantool modules or/and applications used it's own mechanisms of manipulating and persisting spaces metadata. Seems that it's time to make single source of truth for the following metadata:

1. Human readable space name - (string). The main difference from box.space[name] is that human readable space name may contain spaces and even a short description of space contents.
2. Space description - (string) - Short but exact description of space in a few sentences.
3. Field description - (string) - Short but exact description of each field of the space in a few sentences.
4. Field validation rules - (table) - a number of rules to validate space field input data.
5. Index description - (string) - Short but exact description of index in a few sentences.

[vrogach2020]

@no1seman would be nice to:
1 understand what features can be unblocked by this issue
2 describe shortly the case when 'Human readable space name' solves a real problem
3 describe format of validation rules and their use cases

[no1seman]

@vrogach2020

1. Spaces and fields metadata is used in many scheme standarts: swagger, json-api, json-schema, GraphQL, avro and so on and so on. What if you need to use in your application not only one of them but for example GraphQL and Swagger? In that case you have to sync schemes by any custom mechanism instead of having one place where to store that info and write universal module that will be compatible with any future ones that lays on suggested API.
2. It's a common property in all scheme standarts mentioned in previous paragraph.
3. For example, look into json-schema validation standart: http://json-schema.org/draft/2020-12/json-schema-validation.html The common approach is that we have to have the same validation rules both on Tarantool side and client side: WebUI App, Java driver and so on. If we will store validation rules in one single place in one single format - then we will ba able to reuse them in different cases.