[AdaptiveTree] Rework of manifest update params

[CastagnaIT]

Description

After reading DASH specs for "MPD update" the "type" tag must be present in the MPD to distinguish LIVE and VOD content,
so i made the decision to remove the "full" parameter of inputstream.adaptive.manifest_update_parameter then cleanup and rework related variables, now if a MPD is declared dynamic we always enable manifest updates.

the old inputstream.adaptive.manifest_update_parameter property is now deprecated and replaced by
inputstream.adaptive.manifest_upd_params that has the same meaning, but

• ofc no "full" parameter support
• can be used to always add parameters to the manifest update url
• property name renamed to have a consistent name with the other properties
  I do not know if there are any other video services that use it except youtube

breaking change because "full" behaviour is removed,
@glennguy if you have some other live MPDs to test try play them

in the DASHTreeTest i have introduced a way to make manifest update tests which can be expanded as needs see updateParameterLiveSegmentStartNumber

Motivation and context

Followup of PR #1267 to finish wip changes

How has this been tested?

from what i understand there can be two main cases for live:

1. regular live stream declared type=dynamic
2. live content but shown as on-demand, its declared type=static with availabilityStartTime tag value and "live" to profiles tag
3. regular live that when ends, it still accessible as VOD https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#timing-mpd-updates-theend, im a bit unsure that this is currently handled idk

tests for points above:

1. tested couple of sample dash live and facebook live
2. https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd
3. atm i dont have a test stream, in theory FB live become LIVE to VOD when live ends, i notices in some occasions that some problem happens, but atm i cant confirm that its really related

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• I have read the Contributing document
• My code follows the Code Guidelines of this project
• My change requires a change to the Wiki documentation
• I have updated the documentation accordingly

[glennguy]

Thanks @CastagnaIT . I never understood why we had the 'partial' DASH updates way of doing things, make much more sense to have 1 way.