Ability to have sensor entities or binary entities as parameters to read from yaml for an app

[suddenelfilio]

Breaking change

Yes developers using existing generated code will be impacted with a namespace change of their previously generated entities now in NetDaemon.Common.Reactive.Services

Proposed change

The ability to bind to a typed entity using a scalar config in yaml.
e.g. in the app file there is a property like
public LightEntity MyBedroomLight{get;set;}

and in the app's yaml config there is a config
my_bedroom_light: "light.bedroom"

This will create an instance of a LightEntity (as specified by the property's type) for the entity light.bedroom and inject it for the app to use.

This initial version has most of the default entities implemented together with their default services they expose. If a developer would want to he/she could still generate the entities which only will generate the missing services by extending the according entity or create an entire new entity for the unknown entity types.

Code generation has also been updated to support this scenario.

See this example extending the Netdaemon.Generated.Reactive.ScriptEntity while preserving the defaults from NetDaemon.Common.Reactive.Services.ScriptEntity

 public partial class ScriptEntity : NetDaemon.Common.Reactive.Services.ScriptEntity
 {
        public ScriptEntity(INetDaemonRxApp daemon, IEnumerable<string> entityIds): base(daemon, entityIds)
        {
        }
        public void StopSonosSpeaker(dynamic? data = null)
        {
            CallService("script", "stop_sonos_speaker", serviceData, False);
        }

        public void StopSonosSpeakerOnder(dynamic? data = null)
        {
            CallService("script", "stop_sonos_speaker_onder", serviceData, False);
        }

        public void StopSonosSpeakerBoven(dynamic? data = null)
        {
            CallService("script", "stop_sonos_speaker_boven", serviceData, False);
        }
    }

For this I introduced the RxEntityBase so it did not require me to impact/change the RxEntity implementation, as I do realize they expose a similar CallService method. The new one stays compatible with the code generation and thus does not require a change on that front.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Ability to have SensorEntities or BinaryEntities as parameters to read from YAML for an App #307
• Link to documentation pull request: TODO

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
  => Yeah about that, I have a failing test, but the code concerning it was not impacted by my changes as far as I am aware of.
• There is no commented out code in this PR.
• I have followed the [development checklist][dev-checklist]
• The code compiles without warnings (code quality check)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[helto4real]

Can we keep old namespace for the generated and have new one for this features? I rather not break this if we can find a very good reason to. Cause it will not compile when updating to this version.
Forget it, it will be ok with breaking since we do not generate the code and overwrite it. It will be easy to just replace and do search/replace of exisiting.

[helto4real]

Fix the warnings please. I try to keep the code base free from warnings as a way to keep the code quality consistent