Review template scope points

Current template scope points were written before packages were added to Unity, and this shows in the more focused scope points. It's possible to have a template that shows in `Assets`, but doesn't appear under `Packages`. Similarly, there is poor support for folders that are not part of a PSI project. To get most templates to show, it's best to use the `InUnityCSharpProject` scope, which is very wide, and is being incorrectly used - it should say that you're inside a C# PSI project, but it's also set when there is no project for the current folder. Also, it lets you create a `.cs` file in the project root, at the same level as `Assets`, which is not allowed.

We should change the focus of the scope points from PSI projects to the file system, which will allow our templates to work in folders that are not part of a C# PSI project, which makes the Assets View more intuitive. Something like:

* "Unity project folder" - current context is inside a Unity project folder structure
Would not be set for external packages
Will be set even if there is no current PSI project
Might also need a minimum version (for `.asmdef` template). Would have to be optional.
Might need to be a mandatory scope point
Is this the base type of all other scope points? How does that work if it's mandatory?
* "Assets folder" (derived from "Unity project folder"): `Assets/**`
* "Packages folder" (derived from "Unity project folder"): `Packages/**`
Would use to only add `.asmdef`. Scripts and other assets are not allowed here
* "Where assets are allowed" (derived from "Unity project folder"). `Assets/**` and under assembly definition folders
Anything under assembly definition will include `Packages/**`, but only where it makes sense to add packages. I.e. you can't add an asset to `Packages/foo` if that folder doesn't have both `package.json` and a `.asmdef` file
Used to add assets (`.asmdef`, scripts, shaders, etc.) to any folder, in PSI or not.
Will also be set for packages that are external to the project root, even though it derives from "Unity project folder"
This will be the most used scope
* "Editor folder" (derived from "Where assets are allowed"): `**/Editor/**`
Matches any editor folder, under `Assets`, `Packages` or any other assembly definition. Includes firstpass editor folders
Allows templates for editors, edit mode tests, etc.
* "Firstpass folder" (derived from "where assets are allowed"):
* `Assets/Standard Assets/**`
* `Assets/Pro Standard Assets/**`
* `Assets/Plugins/**`
Allows templates for plugins
* "Firstpass editor folder" (derived from "firstpass folders"):
* `Assets/Standard Assets/**/Editor/**`
* `Assets/Pro Standard Assets/**/Editor/**`
* `Assets/Plugins/**/Editor/**`
Allows editor templates for plugins

Notes:

* Do we need a separate check for C# being supported? We basically assume that a Unity project is C# - do we have to add that check into the templates? I'm not aware of any other project system for Unity that allows using other languages
* "Where assets are allowed" is likely to be the most used scope. It will work for `Assets/**`, packages under `Packages/**` and packages that live outside of the project root
* "Where assembly definition is allowed" could be a scope. Anywhere under `Assets/**`, and anywhere alongside or under a `package.json`. This would need a version check, as `.asmdef` was introduced in
* We won't have a specific runtime folder or firstpass runtime folder. I think Editor should be treated as a superset/specialisation of runtime, rather than as two different sets. In other words, anything for runtime will also work in Editor. But conversely, Editor will not necessarily work for runtime.
* Could add a scope for `Resources`? Wouldn't have a default template to use there, though.
* If we're rewriting all of our scopes, do we need any migration for user templates?

Start by tracing the existing template scope points, especially InUnityCSharpProject, and compare how Assets, Packages, external packages, and non-PSI folders are classified. Review the proposed derived scopes and the open questions about version checks, C# support, and user-template migration; done requires an agreed scope model before implementation.

Written by the indexing model from the issue text.