Support tokens with value features and improve format options

[Kieranties]

Description

In the current implementation, tokens are managed as explicit types that are directly added and invoked to parse/apply to a string.
While this works, it leads to a few issues:

• New tokens must explicitly implement a token string - currently this could be anything (meaning new tokens may not follow a convention)
• Tokens cannot define options - e.g. sha7 is required because there is no other way to communicate truncation of the sha token
• Tokens must be explicitly added into a format - e.g. Semver1 and Semver2 must be modified.

Proposed Solution

Tokens should be implemented through a convention that allows:

• Each token handler to be discovered dynamically
• Each token handler to define a token prefix with an optional postfix that identifies a format or processing feature
• Each token handler to be requested directly through a cache - so that if multiple formats request the same token re-evaluation does not occur
• Pre-defined formats such as Semver1 and Semver2 should simply evaluate a pre-defined collection of tokens

This work would also pave the way for new tokens and new custom formats to be added.

Test Cases

{sha} => full sha string
{sha:7} => first 7 characters of sha
{timestamp} => full timestamp
{timestamp:YYYY} => four digit year
{label:-} => label concatenated with '-'
{version:M.m} => Major.minor version string

Additional context

1. Existing tokens that are replaced with the new syntax should be marked as obsolete in the short term.
2. Care will need to be taken to ensure circular token references do not occur (e.g. label may appear in a format string, but not in the label itself)

This will simplify: #47, #75, #92, #114

[Kieranties]

Working branch https://github.com/Kieranties/SimpleVersion/tree/feature/token-improvements