merge of configurations (such as dependencies, pkg)

[davidfirst]

Currently, merge (e.g. bit lane merge or bit merge) only merges component files.
What if the current component has a dependency with version X and the other lane I'm merging have this component with version Y.
What happens now is that we leave the configuration as is. In this case, the version will be X. As a result, if dependencies were updated on the other lane, I'll never get the updates.

Discussed with Ran. In short, this is the plan.
We let Git merge file. Configuration is JSON, which Git is not good at with merging. We have at hand both versions, ours and theirs. Also, during the merge, for git, we find the parent of these two versions. We should use these 3 JSONs, the parent, ours and theirs to understand if there is any conflict. If not, all is good. Use the merged configuration.
If there are conflicts, we can use "theirs" by default and show the user how the configuration was resolved and let the user options how to change (more on this later).
Aspects that provide config can override the default-merge strategy. For example, dependency-resolver will want to use semver to identify and resolve conflicts. Also, aspects could provide a clear output when conflicts are found so it'll be easier for the user to understand.
If the user is not satisfied from the config resolution, bit aspect set can be use in many cases to set a different config. For dependencies, another task of implementing bit deps set could help once ready. Other aspects, we probably should figure out later how to let users an easy way to change.

During merge, we don't always snap-merge. e.g. when there are conflicts in the files or when the user choose --no-snap flag. In this case, we save the component in the unmerged file with the head of the other lane. When the component is loaded, we should use this to calculate the config. This way, bit show will show the correct config after the merge, and bit snap will have the correct config to save into the objects.