[FEAT] `extends` in design components should be included in API docs.

[xelaint]

💡 Feature request

Feature Name

extends in design components should be included in API docs.

The Desired Behavior

i,e. in Button, DaffButtonBaseDirective should be included in API docs.

Your Use Case

Prior Work

Environment

Daffodil version: X.Y.Z
Angular version: X.Y.Z 

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[damienwebdev]

The intended design is as follows, we considered :

export class ClassC {
    public probC: string;
}

export class ClassB extends ClassC {
    public propB: string;
}

export class ClassA extends ClassB {

}

//public_api.ts
// export { ClassA, ClassC };

// Docs Version 1
// ==
// All public properties of all parent classes in the child class, no extends, regardless of whether parent is in public API.
export class ClassA1 {
    public propB: string;
    public probC: string;
}

// Docs Version 2
// ==
// Public properties of all parent classes that are private,
// properties of public parents are omitted and its upon developers to follow to the parent.
export class ClassA2 extends ClassC {
    public propB: string;
}

// Docs Version 3
// ==
// Public properties of all parent classes that are private,
// Properties of public parents are omitted and its upon developers to follow to the parent.
// If developers want to traverse the tree in doc, there's a tree to see the props of the parent classes.
export class ClassA3 extends ClassC {
    public propB: string;
    // > Parent
    //     public probC: string;
    //     > Parent
    //         public propZ: string;
}

We chose:

• ~~ "Docs Version 1" suffers from looking ridiculous with large public class heirarchies.~~
• "Docs Version 2".
• ~~"Docs Version 3" is nice to have, but probably unnecessary ~~

[griest024]

We should always hoist inputs and outputs, this will be affected by #3544