Added pipe standard type 'heating pipe'

[EPrade]

Added a standard type for heating pipes.

The reason for this addition is, that in literature and industry the parameter for heat loss specified is predominantly U [W/mK] instead of alpha [W/m²K].

• I added a csv file from a DH pipe manufacturer for parameters ajar to the existing pipe.csv.
• In create_empty_network a new function parameter 'type' has been added to chose between 'generic', 'gas' and 'heating'. At the moment 'heating' uses the new data and 'generic' and 'gas' use the old. Maybe we should specify here for water(if there are specific parameters for this type of pipes?) or just drop either 'gas' or 'generic' and only differentiate between gas and not gas.
• I created the function 'add_heating_std_types' from 'add_basic_std_types' which extracts data from the new csv and calculates alpha from the given U values

[codecov[bot]]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

:exclamation: No coverage uploaded for pull request base (develop@7d82b3f). Click here to learn what that means. Report is 18 commits behind head on develop.

:exclamation: Current head 7152f68 differs from pull request most recent head cd259c5. Consider uploading reports for the commit cd259c5 to get more accurate results

Files	Patch %	Lines
pandapipes/create.py	42.85%	4 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #569 +/- ## ========================================== Coverage ? 85.10% ========================================== Files ? 90 Lines ? 6209 Branches ? 0 ========================================== Hits ? 5284 Misses ? 925 Partials ? 0 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[SimonRubenDrauz]

Thanks for the contribution. I think this is a good idea. In my opinion, however, I think we should not add a second pipe.csv. I would rather extend the exisiting pipe.csv and add Nones for the pipes which do not have U values. The reason is that, if you implement it your way, at two different places the user needs to decide whether she/he has a heating or a non-heating system - at the beginning, when he/she creates the net, and during the pipeflow (this could lead to unitended errors). Furthermore, in future it could be that it might be interesting to investigate a heating/gas grid. For example in case of a steam network. In that case we would need to change your implementation again, which would affect convert_format and make thinks quite comlicated. This is my feeling. @dlohmeier, what do you think?

[EPrade]

@SimonRubenDrauz @dlohmeier I updated the pull request. Could you take a look again?