Analyze command - track "SerializeReference" usage #53

The SerializeReference feature of Unity Serialization means that additional C# classes can be serialized directly inside MonoBehaviours and ScriptableObjects. These object instances are called "Managed References" (although SerializeReference is the more visible name because that is the C# attribute)

More docs about this feature:
https://docs.unity3d.com/6000.6/Documentation/ScriptReference/SerializeReference.html

They do not use MonoScripts to managed the C# type - instead the C# type info is serialized directly into the serialized reference registry of the MonoBehaviour.

So the information about what types are actually used is spread all over the place in the built content, and it is difficult to see it.

Management of these objects can be a challenge, often we have to do text searching of the YAML format in the project assets to find them. In binary data its quite hard to "find" them without actually loading the content.

One example for wanting to find them is if you want to rename a class and need to confirm that the old name is not present anywhere in your assetbundles.

This feature idea is to add another table similar to the recently introduced mono_script table.

When we enumerate MonoBehaviour objects when we discover a SerializeReference instance we will add a row to the new table that has the assembly name, namespace and class, the riid, and the id of the MonoBehaviour. Ideally we would also capture the size of the serialized data for that object.

This approach will automatically catch managed reference objects on ScriptableObjects, because that C# class is also presented as MonoBehaviours in serialized data, e.g. they are the same native object.

This implementation should be somewhat similar to how references are captured and recorded in the refs table, so it should be possible to implement in UnityDataTools without introducing any new concepts or complexity. Our typetree walking code already knows how to parse all serialized forms of the ManagedReferenceRegistry, so it should not be hard to report them as we parse them, during object analysis.

• As part of this task also introduce one or more views that shows information from the new table, similar to the new script_object_view.
  E.g. a view that shows all SerializeReference objects with these fields:

monobehaviour object id, MonoBehavior name, archive, serialized file, Class, NameSpace, Assembly Name, managed reference id ("rid"), size

• Also update documentation to talk about the new table / view and use case for using it.