What exactly is a component ?

Yes you have the right intuition. Though it's a bit more convoluted than this ^^. First of all Unity is a C++ engine. So all core elements of the engine are written in native C++ code. Mono / .NET is just the scripting layer. Every class derived from UnityEngine.Object has a corresponding representation on the native side. Most built-in components like Renderer, Collider, Transform, AudioSource, ... are completely implemented on the native side. The classes you use in scripting are pure managed wrapper classes.

Yes, Unity has a list of components for each gameobject. However this list is stored on the native side. All components which are derived from MonoBehaviour are essentially the same thing from the engine's perspective. So on the native side your "ForceAdder" component is just an instance of an internal C++ MonoBehaviour class. Of course the instance has a linked managed class (your actual .NET class). When you attach a component to a gameobject Unity will create an instance of it's internal MonoBehaviour class and also an instance of your managed class using the default constructor. This construction of your class can happen from anywhere in the native code. This is often done from a seperate loading thread in the background. That's why you shouldn't implement your own constructor because most of the managed Unity API is not thread safe and can not be used from outside the main thread.

For every MonoBehaviour derived managed class Unity stores some meta data on the native side. So when your code is compiled Unity analyses your class and searches for known callback methods and remembers those facts about your class. During the execution of a frame the Unity core just executes those special callbacks on your component instances when appropriate. I think here it's the best point to mention the Script Execution Order documentation.

Of course the managed land works quite different from native code, especially in regards to memory management. In C++ you have to explicitly destroy objects you don't need anymore in order to free the memory. In managed code this is not possible at all. Objects and memory management is completely under control of the garbage collector. So you can not explicitly destroy or remove the memory of a managed object. However we have the Destroy method which can destroy any UnityEngine.Object derived managed type. Though what this method actually does is destroying the native part of the object on the C++ side and mark the managed part as "dead". The managed objects are still there as long as they are referenced from somewhere. However Unity implemented [a custom == operator][2] which will "pretend" that a dead object is null / not existent.

A similar thing happens when you create a MonoBehaviour derived object manually with "new". The object is actually created on the managed side. However it doesn't have a native counterpart and is automatically considered "dead". Unity essentially doesn't even know that this instance exists. Since Components can only be attached to gameobjects and can't really exist without the hosting gameobject, Unity did not provide any way to create a component manually yourself. To create an instance of a gameobject you either have to drag and drop the script onto a gameobject in the editor so Untiy will properly create a component on the native side, creates the managed object for you and links everything properly, or you can use the AddComponent method of the gameobject class to do the same thing from code.

[2]: https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/