[API] Layer API simplification

[knok16]

Layer is a core concept of the library, so it will be beneficial to keep it as simple, concise, and straightforward as possible. To achieve this simplicity I suggest the next changes:

1. Remove unnecessary logic from Layer, split it into smaller subclasses that will encapsulate one particular aspect of the Layer, convert Layer class into an interface.
   • Introduce ParametrizedLayer/TrainableLayer interfaces to cover corresponding concerns of the layer (discussion [API] [Layers] ParametrizedLayer/TrainableLayer interfaces to represent presence of parameters and trainability of the layer #217, example: [WIP] Added ParametrizedLayer and TrainableLayer interfaces #222)
   • Move weights accessors into the model (plus remove parentModel field since it was needed only to access session to support weights functionality on Layer level) (example knok16@4dc0286)
   • Remove fanIn/fanOut fields since they are used only for local calculations and most importantly are not filled most of the time (example knok16@a76ed7c)
   • Remove KGraph argument from build method (example knok16@cac310d)
   • Introduce NoInputsLayer/SingleInputLayer/MultipleInputsLayer that will represent layers by arity of its inputs (discussion [API] [Layers] introduce separate Layer's subclasses to represent number of layer's inputs #224, example knok16@8643a87)
   • Replace hasActivation method with marker interface (something like LayerWithActivation, example knok16@bd74c40)
   • Make name abstract in Layer - anyway we have it as a parameter in all subclasses, so after this change subclasses will override it right away instead of passing it to the parent class (example knok16@d3d4196)
   • Combine computeOutputShape, build and forward methods into a single one (build for example) (example knok16@433b664), that way it will be easier:
     • for an implementor of the layer, since it will be required to implement the only single method with clear semantics: it should build the layer
     • for users of layers, since layers will have the only single method to call before usage, no problems with the proper ordering of method calls can arise
   • Move inboundLayers/outboundLayers/invoke to Functional builder: it is useful only in the scope of the functional builder, and stores data required for it
2. Split layers into 2 separate interfaces: LayerBuilder and Layer, leaving all preparation and layer construction to LayerBuilder, and making Layer immutable object that will represent a fully constructed layer.

WDYT?

[zaleslaw]

Great summarization of a few proposals that have been discussed in the past with you. So I suggest arranging a meeting in October with other community members to discuss it.

So, I'll arrange the meeting and invite you to come and discuss it.

I suppose that when the most part of the required Keras functionality is implemented, we could move forward to make KotlinDL more kotlinish!

[knok16]

great! agree that it should be discussed and I'm ready to do it.