Interface type is documented in Lexicon.rst:
The type of a value or declaration outside its generic context. These types
are written using "formal" generic types, which only have meaning when
combined with a particular generic declaration's "generic signature".
Unlike contextual types <contextual type>, interface types store
conformances and requirements in the generic signature and not in the types themselves. They can be compared across declarations but cannot be used directly from within the context.
For example, say you have something like a polymorphic function foo<T>(t: T) -> Int? where T: Collection, T.Element == Int. Then the T: Collection and the T.Element == Int are not stored in the interface type but in the corresponding GenericSignature.
With that, I think parts of the explanation make more sense:
which only have meaning when
combined with a particular generic declaration's "generic signature"
This explains why you need the GenericSignature -- it doesn't make sense to interpret the interface type without it (or at least, not fully, you can still understand some of the structure though) because you are missing out on meaningful information. For example, if you look at Types.h/GenericFunctionType, you'll see that it the factory constructor GenericFunctionType::get takes a GenericSignature to keep track of this.
"type" itself is an umbrella term that encompasses all the different .*Type data structures (and TypeBase, I guess) in the compiler. If you are referring the Type data structure itself, there's a doc comment there which might help:
/// Type - This is a simple value object that contains a pointer to a type
/// class. This is potentially sugared. We use this throughout the codebase
/// instead of a raw "TypeBase*" to disable equality comparison, which is unsafe
/// for sugared types.
"type class" here means some class like FunctionType or BuiltinIntegerType, i.e. something which is a subclass (directly or transitively) of TypeBase. The note about sugar is there because when types are being compared for equality, you want to compare the types without sugar, so pointer equality would have the wrong semantics. There is a comment below reflecting the same point
// Direct comparison is disabled for types, because they may not be canonical.
void operator==(Type T) const = delete;
void operator!=(Type T) const = delete;
By contrast, these operators are overloaded for CanType, which don't have sugar.
You might also find this blog post useful if you're hacking around the AST: The secret life of types in Swift | by Slava Pestov | Medium
