Move temperature conversions to sensor base class (3/8)

[emontnemery]

Proposed change

Move temperature conversions to sensor base class SensorEntity (3/8)

Temperature conversion will only be done for sensors with device class set to temperature.
Temperature conversion will still be done for other sensor entities during a transition period, which will end with Home Assistant Core 2022.3.0.
Temperature conversion for non sensor entities is unaffected by this PR.

This PR migrates sensors in integrations f-h to be compatible with unit conversion in SensorEntity.

Additional PRs will be opened to migrate sensors from other integrations

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• 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:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• 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

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[dgomes]

Why not moving some of these towards _attr ?

[emontnemery]

@dgomes _attr shorthand is supported for the new attributes, but migrating integrations to use _attr should be done with one PR for each integration.
The intention in this PR is to use _attr shorthand if the integration is already using it, otherwise stick with property functions

[scop]

Just an example from huawei_lte, this patch will leave lots of native_value methods behind whose docstring talks about returning the state, which feels a bit off. Better would be to have them mention returning the native value instead. And it also feels similarly off to have a return type named StateType for a method named like this.

Not that big of a deal, but thought I'd mention it. Docstrings would likely need manual work to fix, and StateType thing probably not worth the churn.

[emontnemery]

It's a valid point @scop, we could try to improve most/some docstrings in follow-up PRs depending on how many variations there really are.

[bieniu]

LGTM for gios 👍