Filter by types, categories and properties seperately

[AlanSl]

• Add overridable filter function, isNodeExcluded davidmarkclements/d3-fg#28
• updates to tests
• update against latest master
• update various things based on new v8 category from Simplify code area categories #41
• fixing a bug when parsing a hash that includes disabling merging [update] turned out to be a bug in master, fixed in Fix errors on applying unmerged tree from hash #42

This mostly changes things under the hood:

• Removes the typeTEMP property (long overdue!)
• Uses isNodeExcluded() from shared.js to test for exclusion everywhere - in analysis, in the UI, and pipes it in as an override for the d3-fg test that sets .hide on frames
• Therefore, exclusion tests now check for properties like isInit separately to categories like app, deps, etc, and separately to types like v8, cpp; and for deps, the types are now the name of the dependency
• Namespaces type-based exclusion by category. So, for example, if someone uses the module native as a dependency, there's no ambiguity between deps:native and all-v8:native exclusion filters

This means:

• (the only visible change expected in this PR) It should be more accurate with init frames. It no longer treats init as a type, which means that if an init frame is not from core, it will now tell you so and treat it more appropriately. For example, here's a frame that is init and also from a dependency:

• More importantly, this puts us in a position where we're very nearly ready to add features based on additional types, such as checkboxes to filter out specific dependencies. We just need analysis to generate the list, which is WIP by @goto-bus-stop

This touches on a lot of code so will need thorough testing for regressions.

[AlanSl]

Still needs tests, now works again with the new changes to master, particularly the new core / V8 categorisation. Here's another example of a rare init-but-not-core frame:

[AlanSl]

Here's one regression:

I'll add a commit setting the type for app frames to the app name so such things would be like In profiled application (some-amazing-app)

[AlanSl]

Last few commits tidy up the presentation of the code area text in the info box:

[goto-bus-stop]

code looks good so far (± one structural comment), will play around with it a bit more

[goto-bus-stop]

there's a slightly strange colour variance here:

v8/v8 native have the grey colour, while node/v8 runtime have the greyish greenish one

[goto-bus-stop]

LGTM pending ci/rebase

[cuginoAle]

Late to the party...
LGTM!

[AlanSl]

With #53 merged I can rebase away the last few commits working around the 0x update breaking the tests.

[cuginoAle]

Little heads-up: You might have a Lint error here because of the space between Error and ('

[AlanSl]

Strangely, the linter doesn't mind, but it probably should mind, so I've changed it anyway 🙃

[cuginoAle]

It looks good to me.
One thing that would be relevant for this as well : we currently throw and error if no node is selected, that means we shouldn't be in a scenario where no data is displayed (either because the user filtered everything out or simply because 0x didn't collect any data).
Maybe we could notify the user that there's no data available showing a Message rather then throwing an error?

[AlanSl]

The difficulty with that issue is that there are lots of points in the process that assume that data exists and it's difficult to stop them all from hitting errors. Most components expect something on each update.

That comment has however given me an idea for a different way to solve the problem... and it seems to work. Will post a PR shortly, after merging this one.