Unit Cycle Fixes & Cleanup SyntaxTreeBase

[InsertCreativityHere]

The classes we use to represent Slice definitions in the parser rely heavily on inheritance. The base of all these types is SyntaxTreeBase. This PR's focus is on moving stuff out of SyntaxTreeBase and into more appropriate places,
further up the inheritance tree.

Specifically:

• SyntaxTreeBase has a default implementation of visit which is no-op. This is bad.
  It means that you can call Builtin::visit. But what does it even mean to visit a built in type?
  This visit function was moved up to Contained, which represents a Slice definition.
  These are the only sensible things to visit.
  Also, visit is now pure virtual. Every type should (and does) implement it's own visit logic.

• SyntaxTreeBase also holds a UnitPtr field. This was removed.
  We had to jump through hoops to get this to work for Unit, since this means it holds a shared_ptr to itself... Also, it made us unable to provide a default constructor for SyntaxTreeBase.
  So. This field was removed and replaced with a pure virtual unit() function.
  Contained holds a UnitPtr field, and returns it in it's implementation.
  Whereas Unit implements this function with shared_from_this.

• By slimming down SyntaxTreeBase in these ways, I was able to completely eliminate it's constructor, along with the constructors for Type and Container.

---

A result of this is that #3358 is fixed.

[bernardnormier]

It would be helpeful to explain which cycles the various destroy() functions break.

[bernardnormier]

I don't understand the logic of destroy(). Which cycle are you breaking?

Update: ok, it's because Unit holds onto a list of Builtins. The modern approach is for the Builtin to hold a weak_ptr<Unit>. This way, no cycle and no need for Builtin::destroy.

[bernardnormier]

I am puzzled by this code: instead of keeping _unit, you could just return _container->unit(), and then you don't need any destroy, since destroy() doesn't clear _container.