add better documentation for BaseTrait and Builder

[i582]

This PR adds more documentation, as an example of the level I would like to see for the entire standard library!

The new documentation for BaseTrait shows how we document code in general.

• We use /// for documentation comments
• "[`Name`]" for references to some symbols, with self referring to the current contract/trait
• Any code examples are wrapped in three apostrophes

The documentation for Builder shows the following aspects:

• Primitives with methods are described in a separate file (in builder.tact for Builder for example), where at the very beginning there is a definition of the primitive Builder; type with a comment attached explaining what it is and examples of use.

  Note that in the old version, all primitives were in one file, which meant that to find the Builder documentation, the user would have to search for this file, in the current version it is easy to find at the beginning of the file.

• For examples we use # Example, this will allow automatic generation/display of headers in documentation and IDE, which should improve readability.
• Some methods appear over time, describing this fact as "Available since Tact 1.5.0." can be error-prone, so we use @since 1.5.0 as in other languages.

I think we need an RFC in which we will describe all such rules that everyone in the team agrees with. Everything described above is negotiable and I will be glad to hear your thoughts on how to further change and improve the documentation rules!

#573

[anton-trunov]

what issue is it solving?

[anton-trunov]

I would argue cells.tact should either be left intact, or split into two files builder.tact (serialization) and slice.tact (deserialization).

[i582]

what issue is it solving?

#573
added to description

[i582]

I would argue cells.tact should either be left intact, or split into two files builder.tact (serialization) and slice.tact (deserialization).

Yeah, if this file layout is ok, I'll rename this file to cell.tact.

There are now also functions like asSlice for Builder and Slice that should be placed somewhere (together in a file like conversions.tact or split into cell.tact and builder.tact).

[anton-trunov]

or split into cell.tact and builder.tact

this is exactly what I'm arguing against:

• it's either everything in one file called cell.tact (or cells.tact as we have now),
• or builder.tact and slice.tact: you simply cannot do anything with cells as those are opaque (except passing around as stack values)