feat: ancestry information persistence within a mapping tree

[Matouš Kučera]

Currently, a mapping ancestry tree should be recomputed from mapping trees every time it is needed.

This introduces unnecessary overhead when dealing with, for example, joined mapping trees that have already had their tree computed before they were persisted into a file or alike. A practical example of this overhead is the generator-accessor module, whose generator is expected to be able to be invoked frequently (e.g. accessor rebuilding after a buildscript change in generator-accessor-plugin).

I propose to provide an API to easily persist an ancestry node identifier, such as a hash of the oldest mapping set or a simple integer index of the node in the tree, in a namespace for each class and their members. This allows for rebuilding the ancestry tree without incurring the large CPU cost of comparing names.

An index-based mapping example in Tiny v1:

v1	source	dst_ns	node
CLASS	a	TestClass1	0
FIELD	a	Ljava/lang/String;	a	testField1	0
METHOD	a	()V	a	testMethod1	0
CLASS	b	TestClass2	1
FIELD	b	Ljava/lang/String;	a	testField	0
METHOD	b	()V	a	testMethod	0

v1	source	dst_ns	node
CLASS	b	TestClass1	0
FIELD	b	Ljava/lang/String;	b	testField1	0
METHOD	b	()V	b	testMethod1	0
CLASS	a	TestClass2	1
FIELD	a	Ljava/lang/String;	b	testField	0
METHOD	a	()V	b	testMethod	0

Instead of comparing the dst_ns names to figure out the relationships between these two obfuscation maps, we can iterate over their members and associate them with their counterparts from another version based on the node index.

This introduces a node mismatch possibility when dealing with multiple obfuscation maps that were created with different ancestry trees, this can be mitigated by using the hash of the oldest mapping set (to a certain extent - collisions).