Implement update rocks with ``cartridge build``

[mRrvz]

Now, if you build a project via cartridge build, and then build it with other rocks (for example, changing their version), then they will be duplicated. We can add the ability to auto-remove unmatched rocks: check the manifest file before each build and remove rocks that do not match using tarantoolctl rocks remove <name>

[Totktonada]

I looked at the tarantoolctl rocks make behaviour in the following case:

1. Add the foo == 1.0.0 dependency.
2. Call tarantoolctl rocks make.
3. Change the dependency to foo == 2.0.0.
4. Call tarantoolctl rocks make again.

After this, there are two modules in .rocks/share/tarantool: foo.lua and foo_1_0_0_1-foo.lua. AFAIU, the former will be used at require('foo') and we should perform some explicit steps to change require()'s behaviour to get foo-1.0.0. I don't know for sure, though.

(BTW, tarantoolctl rocks make say 'Use --force to force removal (warning: this may break modules)', but the behaviour with --force is the same. There is a problem with passing the option down to luarocks? Or it is a problem in luarocks itself?)

(BTW, there is a luarocks issue, which looks relevant on the first glance.)

I need a reproducer for exact problem you meet due to this behaviour to prioritize the task and to decide how to better fix it.

[Totktonada]

I re-asked Alexey about this. He don't remember much details. I think that we should experiment around and investigate behaviour in the scenario with updating a module. At least to gain more knowledge and offer better documetation.