Change main to be like any other lane and support lane versioning

[davidfirst]

This is a preliminary discussion with @ranm8 and I.
Currently, to get the latest snaps when on a lane, the user runs bit import to get the newest objects from the remote, and then bit checkout latest changes the component files and .bitmap.
What happens if after the checkout I want to "revert" the checkout and change back the components to the version they had before? there is no way (without Git) to achieve this currently.
To solve it, we might want to implement versions for a lane. The version will contain bit-ids (per bit-id a version, which is the head back then) and Log. The Lane object will contain "head" to the latest lane-version.
However, we have the same issue with main. Regardless of Lanes. If I run bit import and bit checkout latest I can't go back to the previous versions on main. (unless I do them one by one of course, but I need to remember which version each one of the components was before).
To fix this, we might want to be consistent and treat the main-lane the same as any other lane. Meaning, every scope will have a "main" lane by default, and it'll include all the heads of the components. The Component object, won't store the head anymore.
This way, we can enjoy the same mechanism of versioning for main as well. It's also kind-of solve some of the issues we want from the workspace-component.
These two tasks are not easy to implement, but now is the best time to do it before Lanes is public.

@itaymendel , @GiladShoham , your input is welcome here.

[davidfirst]

I'm wondering about the following scenario:

1. create a new lane with compA which depends on another component from another scope compB. this compB is not part of the lane (bit install. not import).
2. export the lane.
   The remote now has the lane and the components: compA and compB.
   Where the head of compB is written?
   If it was part of the lane, it'd be in the lane object, but it's not. Should it be on the main-lane? it is not part of Main.
   Maybe there is no need for the head at all in this case?

Same thing when you install a component. Do we save the head? where?
If we don't save the head at all, we won't know what is the "latest" of this component. maybe we don't need to.

[davidfirst]

Another point raised by @GiladShoham .
The workspace normally has components from various scopes. When exporting multiple components from the workspace, it needs to go to the different scopes and add them to their "main lane".
This is different than exporting when on a lane, where the export always goes to one scope.

[davidfirst]

Another discussion with Ran.
Maybe lanes and main don't need to be the same.
Instead of having versions of main, we can have kind of log-history. Upon export, we can save the export-id and the components diff: previous and current head. It'll be pretty easy to implement.
As to lanes, implementing version mechanism is complex. Maybe instead of versions with relationship between each other (parents prop), we can have a map with all versions hashes in the Lane object. Each lane-version will have a hash, log and the components data.
We didn't come to a clear conclusion and decide to make decisions about this later.