Add support for Shelly Pro 2 PM

**Describe the problem you have/What new integration you would like**

It would be great to add support for the Shelly Pro 2 PM.
The power monitoring feature allows for example to use this device with the [**Current Based Cover**](https://esphome.io/components/cover/current_based) component to control garage doors/shutters.
The fact that the device has an Ethernet port is very interesting for some use cases.

**Please describe your use case for this integration and alternatives you've tried:**

**Additional context**

I've received a Shelly Pro 2 PM recently.
The only difference with the Shelly Pro 2 is the addition of two [**ADE7953**](https://esphome.io/components/sensor/ade7953.html) chips (one per relay sub-board).



There are two challenges to support this board:

### -> Common reset GPIO for both ADE7953

Both ADE7953 reset lines are connected to one single GPIO (GPIO2).
So by default, if we don't do anything, that GPIO will be low and hence asserting the reset of both chips forever.
This will prevent the ESP32 from getting meaningful data from them.

I've tried to modify the ADE7953 driver in order to support a new **rst_pin** field. Because it looks like it would be much cleaner if this pin is handled by the driver itself. This works well when there is only one ADE7953, but it feels it's not the right solution when there is one common reset pin for several devices.

How could we modify the ADE7953 driver so that it could support several "children" that are the actual devices?
That way, the parent would have a **rst_pin** that could be common to all children.
[This is what Tasmota did](https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xnrg_energy/xnrg_07_ade7953.ino).

### -> Bug when using ADE7953 with esp-idf framework

The default value for `voltage_gain`, `current_gain_*` and `active_power_gain_*` is **0x400000**.
But with ESP IDF framework, the value **0x200000** ends up in the registers.
The bug looks like this:

- When putting 0x400000, we read 0x200000 from the device registers
- When putting 0x200000, we read 0x100000 from the device registers

For now, I went around both problems in my [**esphome-devices PR**](https://github.com/esphome/esphome-devices/pull/999) here, but let me know if you have ideas to solve the root cause of those issues!

Start by reading the ADE7953 driver and the existing Shelly Pro 2 support, then compare the proposed parent/child reset arrangement with the linked Tasmota implementation. Reproduce the voltage, current, and active-power gain behavior under the ESP-IDF framework. Done means Shelly Pro 2 PM power monitoring works with its shared GPIO2 reset and correct register values.

Written by the indexing model from the issue text.