Project import tree improvements

Following #4805 and #5639 there are some pending items we are considering for the project import tree:

• Imports tree should support duplicate node names (#5711, PR #5736)

• Review whether ordering of children in tree reflects ordering of imports, including in the case of updates that change order (#5754, PR #5736, PR #5775)

• Browse object showing path, label, group label

• Option to show these at all times

• Include imported files in “Find in Files”

• (Maybe) track “Show all files” state via Dataflow

• Indicate when, in the import ordering, the project (eg csproj) is evaluated (requires change to MSBuild and may not be feasible)

• Investigate the ‘Search within file contents’ option of Solution Explorer’s search:

• Review context menu on the “Imports” node

• While the import tree is visible, drag/dropping the project’s .csproj.user file into the editor gives:

  ‘ClassLibrary1.csproj.user’ cannot be opened. The file is not supported.

[drewnoakes]

• Review whether ordering of children in tree reflects ordering of imports, including in the case of updates that change order (#5736)
• Indicate when, in the import ordering, the project (eg csproj) is evaluated.
• Investigate the ‘Search within file contents’ option of Solution Explorer’s search:

[davkean]

Find in Files:

• It appears that the new search only searches folders that return GUID_ItemType_PhysicalFolder for VSHPROPID_TypeGuid and does not respect VSHPROPID_IsNonSearchable. The imports node is a virtual folder and is not considered GUID_ItemType_PhysicalFolder, nor do we want to for it to be considered that as that brings other behavior along with it, such as provided a file name from ProjectItem.FileNames.