…ate-key)

The capsule base-dir is normally a `sha1` of the workspace/scope dir,
which is 40 chars long. Problem is that Windows is not happy with long
paths.
This PR uses a shorter hash. The number 9 is pretty random, it's what we
use for short-hash of snaps.
We're aware of an extremely low risk of collision. Keep in mind that in
most cases you won't have more than 10 capsules in the machine, so it's
fine.

…ing easier (#8828)

With this flag, no need to push to the remote in order to investigate
the `Version` object changes.

currently, if there are local changes in the component.json (generated
by `bit config eject-conf`), then `bit checkout reset` doesn't reset
them. It leaves the file as is.
This PR refactors the way how this component.json file is saved to reuse
the infrastructure we had for package.json (with indent and EOL taken
into account). With this, it was easier to change the component-written
command to make sure this file is written if it was there before.

…d by "bit remove" (#8829)

…onents (#8830)

Otherwise, the components that depend on these removed aspects are
trying to load them, find out they don't exists, then trying to import
them and throw an error "unable to import".
Because these removed aspects are new, there is no easy way to fix this.
It's impossible to install them as packages.
This PR blocks it unless `--force` flag was used.

…plate name (#8831)

Otherwise, the code might have a class that extends itself. 
For example, `bit create node-env node-env` produces `class NodeEnv
extends NodeEnv`.
Or `bit create react-env envs/react-env --aspect
teambit.react/react-env` produces `class ReactEnv extends ReactEnv`.

remove the duplicate "error".

This command is useful when you got a messy merge state that from one
hand you don't want to loose the changes, but on the other hand, you
want to keep your lane without those changes.
This command does the following:
1. create a new lane with the current merge state. including all the
filesystem changes. (in practice, it leaves the fs intact).
2. reset the current lane to the state before the merge, so then once
done with the new lane, you can switch to the current lane and it'll be
clean.

)

Also, when a component has issues, replace the " ... ok" with "...
issues found".

…en on a lane (#8836)

We used to throw an error suggesting the user to import the components
individually. The reason was that when you're on a lane, you probably
want to import components from the lane. not main. That's why when the
wildcard matches both, lane and main, only the lane are imported.
However, if only components from main are matched, it's not very clear
whether you really want to import from lane, or your wildcard syntax
didn't bring the results you thought it would.
With this PR we assume that in this case you do want to import from main
so we let you do that.

…e of objects rather than trying to fetch them (#8839)

This will be actually used once remotes are updated and support the new
GraphQL query.

Once deployed on the remote scopes, it can help a client in negotiating
with the server and adjusting API compatibility.

When the `bit scope-rename` (or `bit rename`) suppose to change multiple
values in the workspace.jsonc, it was changing only the first one.

…t from specific files (#8806)

…ge (#8844)

Similar to `bit deprecate --range`, this new flag allows deleting
specific tags. For example `bit delete my-comp --range 0.0.1`. It marks
0.0.1 only as deleted.
This is supported in `bit log`. It's also shown in the `bit import` and `bit show` output. 
For example, when running `bit show [email protected]` the "removed" is false. 
However, `bit show [email protected]` shows it as true. It also shows the range.

Until now, `.gitignore` files were always ignored by default and never
tracked by Bit.

## Proposed Changes

- track `.gitignore` files. This way, when multiple users import the
same component and using different git repos, they could use the same
.gitignore file.
- in case `.gitignore` is found in the component root-dir, Bit reads it
and uses it to untrack component files.
- in case `.bitignore` is found in the component root-dir in addition to
`.gitignore`, the `.bitignore` takes precedence and is used to untrack
component files. (still, `.gitignore` itself is tracked). This way, it's
possible to have different patterns/rules for bit and git.
- until now, bit was searching for the `.gitignore` of the
workspace-root, now only in the workspace-root, but also upwards until
it finds it. This is unintuitive and can cause confusion. It was changed
to use only the one in the workspace root.

This is done via `bit ws-config` for awhile now

…t use" (#8848)

…#8845)

…or (#8850)