Bump version to 0.3.0

[ainyan03]

Release preparation: bump the version to 0.3.0 (library.json / library.properties /
idf_component.yml / src/gitTagVersion.h). The minor version rises because this
release changes public APIs on the IO expander and PMIC classes; everything below
is a source-level or behavioural change from 0.2.20, listed here so it can serve
as the migration reference.

Breaking: M5PM1_Class::pwr_src_t is now a bitmap (#316)

The enumerators changed value, and getPowerSource reports every source that is
currently valid rather than one exclusive state.

0.2.20	0.3.0
vin = 0, vinout = 1, battery = 2, unknown = 3	none = 0, vin = 1 << 0, vinout = 1 << 1, battery = 1 << 2
getPowerSource() == battery	getPowerSource() & M5PM1_Class::battery

This is the one change here that does not announce itself: equality comparisons
against vin, vinout or battery still compile and must be rewritten as bit
tests, because the values moved — battery used to be 2, which is now the value
of vinout. Only code naming the removed unknown fails to compile. Bit 1 reads
0 while the 5 V boost is enabled, and more than one bit can be set at once.

Breaking: the IO expander pull API takes an explicit mode (#320)

0.2.20	0.3.0
enablePull(pin, true)	setPullMode(pin, pull_up) or setPullMode(pin, pull_down)
enablePull(pin, false)	setPullMode(pin, pull_none)
setPullMode(pin, true)	setPullMode(pin, pull_up)
setPullMode(pin, false)	setPullMode(pin, pull_down)

enablePull is removed and setPullMode takes IOExpander_Base::gpio_pull_t
instead of a bool, so every old call fails to compile: a bool does not
convert to an enumeration. It also returns bool now, true only when the
requested state was fully established, so a partially failed I2C write no longer
leaves both resistors enabled silently.

Two defects disappear with it. On M5IOE1_Class, enablePull(pin, true) set the
pull-up without clearing the pull-down, so a pin that already had a pull-down
ended up with both. On PI4IOE5V6408_Class, nothing ever enabled the pull
register, so pull-ups worked only because the power-on default happened to have
them enabled.

Breaking: the PWM duty methods state their unit (#321)

0.2.20	0.3.0
M5IOE1_Class::setPwmDuty(0, raw, enable, polarity)	setPwmDuty12bit(pwm_ch1, raw, polarity, enable)
a numeric channel	pwm_ch1 … pwm_ch4 (underlying values 0-3 unchanged)
a bool polarity argument	m5::pwm_polarity_t::normal / ::inverted

setPwmDuty no longer exists; percent and raw values go through
setPwmDutyPercent (0-100) and setPwmDuty12bit (0-4095). On M5IOE1_Class the
last two arguments also swap from (enable, polarity) to (polarity, enable),
matching M5PM1_Class and the standalone M5IOE1 and M5PM1 drivers, whose
setPwmDuty means percent. The old name is left vacant so a call written against
either meaning fails to compile instead of changing behaviour. The channel
parameter is pwm_channel_t rather than a number, duty parameters are
std::uint32_t with out-of-range values rejected rather than masked, and the
methods return bool.

Breaking: M5IOE1_Class::setPwmFrequency returns bool (#322)

The I2C write status is returned instead of discarded, matching
M5PM1_Class::setPwmFrequency. Ordinary calls that ignore the result stay
source-compatible; only code that depends on the exact member-function type has
to move from void (M5IOE1_Class::*)(std::uint16_t) to
bool (M5IOE1_Class::*)(std::uint16_t).

Added

• M5PM1_Class gains PWM control: setPwmFrequency, setPwmDutyPercent and
  setPwmDuty12bit (Add PM1 PWM control and use it for the ToughC5 buzzer #318).
• ToughC5 configures its buzzer line at startup, so a buzzer left sounding by
  another firmware is silenced before begin returns (Add PM1 PWM control and use it for the ToughC5 buzzer #318).

Fixed

• Tab5 reported the battery current with the wrong sign (Tab5: fix the battery current sign #317).

[ainyan03]

Closing for now: more changes are planned before the next release, so the version bump comes later with the full set. The migration notes here will be carried over into that release.