Add missing slash to make pattern accurate, since the JetBrains folder is always relative to root assets folder.

Unlike other packages, TextMesh Pro is not entirely managed by Unity's new Package Manager, and still imports some assets directly into the project.

... to let the file point to its canonical source

When a Unity project is opened in Jetbrains Rider, it installs a editor plugin into the Assets/Plugins/Editor/Jetbrains folder to manage Unity->Rider integration. This plugins life cycle is managed by your local Rider install and is automatically updated by Rider. It should not be committed to source control.  This is documented by Jetbrains here https://www.jetbrains.com/help/rider/Unity.html

This change should ignore both the Jetbrains plugin folder and its .meta file correctly. For completeness, it would be nice to also ignore the /.idea*/ settings folder that Rider autogenerates, but i see a PR implementing that change has already been rejected.

* Added leading slashes to ignored directories so that valid subdirectories aren't ignored incorrectly

* Added comment to recommend .gitignore placement; added leading slash for AssetStoreTools rule

* Added a leading slash to never ignore .meta files in the root Asset folder

Only people building Unity plugins will need to import the asset store tools plugin into their project, and it's a toss up whether they want to commit the tooling into their repo (they might or they might not want to, it highly depends on their workflow). The default .gitignore shouldn't be making this choice for these users.

Unity projects targeting the 2.0/3.5 runtime or built with mono < v5.0 generate `mdb` files, not `pdb` files.

Looks like the `crashlytics-build.properties` gets around in more than just the `StreamingAssets` folder, looking at [examples around the internets](https://github.com/auth0/sharelock-android/blob/master/app/src/main/assets/crashlytics-build.properties), so it should probably just be ignored as a filename.

Add ignore for Crashlytics generated file

/.vs/ do not catch the visual studio cache folder but .vs/ do

* Update Unity.gitignore

Prevents directories: `Library`
`Temp`
`Obj`
`Build`
`Builds`
`Assets/AssetStoreTools`
from being included in the remote if the project sits in the `Assets` folder.

* removed wildcards from Unity's .gitignore

Prevents directories: `Library`
`Temp`
`Obj`
`Build`
`Builds`
`Assets/AssetStoreTools`
from being included in the remote if the project sits in the `Assets` folder.

Since the version 5.2, Unity has used Visual Studio 2015 instead of MonoDevelop as default script editor in Windows.
This change may be helpful for Unity developers who use the recent version of Unity in Windows.

	modified:   Unity.gitignore

Ignore build, MacOSX and Windows files

With the current setup these folders are ignored in the whole repo, but they're only automatically generated in the project root so it makes sense to only ignore the ones in the root.

I made this change because one of the assets in my project uses a folder called 'Library', and I was wondering why it never uploaded that folder.

And removes the last new line.

Removes queried extensions.

By having the leading `/` infront of the `*` makes these types of files relative to the directory the gitignore is in. If you create a Unity project inside of a git directory Unity forces you to create a new directory, thus not picking up these files.

Ignore the build directory in case a Unity build is initiated in the project.

Sysinfo.txt is generated by unity if occurs any crashes. The content consist of  users system information, running process etc. I don't think that should be shared with others.

Unity only generates project files in the top-level directory.
However, the current .gitignore will ignore all project files even
if they were not generated by Unity.

It is sometimes necessary to include non-Unity project files for
level editors or other utility projects that have been added to the
repository.

*.suo files are binary, user specific files generated by Visual Studio with some user configuration information, thus, don't need to be versioned.