[sonic_platform_base] support new-platform-api-based daemons

[stephenxs]

[sonic_platform_base/chassis]

1. add _eeprom and get_eeprom into class ChassisBase so that syseepromd can access eeprom related stuff.
2. fix typo (non-asic characters)

[sonic_platform_base/sonic_sfp/sfputilhelper]
For xcvrd, originally we plan to remain the module sfputilbase to provide functions like mapping between logical and physical interfaces. However, SfpUtilBase is an abstract class and can not be instantiated. In that case, a new module sfputilhelper has to be introduced to provide the required interfaces.

1. read_porttab_mappings, which reads port_config.ini and generats mappings
2. get_physical_to_logical
3. get_logical_to_physical
4. is_logical_port

[sonic_platform_base/sfp_base]
support interface get_transceiver_threshold_status

[jleveque]

Please fix new conflicts.

[stephenxs]

Please fix new conflicts.

Sorry for the conflict. I'll do it.
But this is also something I'm going to discuss.
Currently I assume the keys of dictionary returned by sonic_platform.sfp.get_transceiver_info() are exactly the same as that by sfputilbase.get_transceiver_info_dict so that we can have a smooth transition. However, according to the comments in front of get_transceiver_info we find the difference. I also suggest having the comments, especially the keys column, updated so that the keys name align with what returned by sfputilbase.get_transceiver_info_dict. There is a similar situation when it comes to other APIs, like get_transceiver_dom_info_dict vs. get_transceiver_bulk_status, and
get_transceiver_dom_threshold_info_dict vs. get_transceiver_threshold_status

[jleveque]

@stephenxs: When fixing the conflicts, please feel free to do what you think is best, and we'll discuss any differences of opinion in review.

Also, unrelated: can you please check my new question on a PR which I already merged?: https://github.com/Azure/sonic-buildimage/pull/3198/files#r309356059

[stephenxs]

@stephenxs: When fixing the conflicts, please feel free to do what you think is best, and we'll discuss any differences of opinion in review.

Also, unrelated: can you please check my new question on a PR which I already merged?: https://github.com/Azure/sonic-buildimage/pull/3198/files#r309356059

Done. Please review. If this style is acceptable, I would also like to update comments of get_transceiver_info.
The only concern is that how if some vendors have already implemented their apis based on current keys.

[stephenxs]

Sure. BTW, if you don’t have other suggestion, I would like to update the comments in front of get_transceiver_bulk_status as well.

@@ -83,45 +83,45 @@ def get_transceiver_threshold_info(self):

======================================================================== keys |Value Format |Information

…

---------------------------|---------------|---------------------------- - Temperature High Alarm |FLOAT |High Alarm Threshold value, + temphighalarm |FLOAT |High Alarm Threshold value, | |of temperature in Celsius. I think it would be fine to keep the Information field on one line instead of splitting into two. The lines might be a bit long, but it should be around 100 chars, so I think it would be fine, and it would make the list shorter.