add more type tags

[withinboredom]

Description

To support something like protobuf, Serde requires more type tags than PHP currently has support for. This adds multiple new type tags that currently do nothing:

• Binary: marks a string as "binary" vs. utf8 (or whatever encoding it is).
• Fixed32: marks an integer or string as a fixed-width unsigned 32-bit integer. This can be represented fully on a 64-bit system, but not on a 32-bit system.
• Fixed64: marks an integer or string as a fixed-width unsigned 64-bit integer. This can be represented partially on a 64-bit system, but not fully.
• Float32: marks a float as a 32-bit float.
• Float64: marks a string or float as a 64-bit float. A string representation may be required on 32-bit systems.
• Int32: marks an integer as a 32-bit integer.
• Int64: marks an integer or string as a 64-bit integer. A string representation may be required on 32-bit systems.
• SFixed32: marks an integer as a fixed 32-bit signed integer. For binary representations, this will always be 32-bits, including padding.
• SFixed64: marks an integer as a fixed 64-bit signed integer. For binary representations, this will always be 64-bits, even if it could fit in a 32-bit number.
• SInt32: marks an integer as a signed 32-bit integer.
• SInt64: marks an integer or string as a signed 64-bit integer.
• UInt32: marks an integer or string as an unsigned 32-bit integer.
• UInt64: marks an integer or string as an unsigned 64-bit integer.

Motivation and context

These type-tags are required for protobuf support to work correctly. There are various differences in encoding for each of these types in protobuf formats. (for example, SInt's are encoded using a zig-zag encoding for more space-efficient representation).

Additionally, other formatters could make use of this. For example, Yaml/JSON could base64 encode strings marked Binary. For string-numbers, it can pass through the string representation as a number instead of encoding a string.

How has this been tested?

These type tags currently have no effect on the output generated. Additional behaviour will come in a followup PR.

Screenshots (if appropriate)

Types of changes

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

• [x] I have read the CONTRIBUTING document.
• [x] My pull request addresses exactly one patch/feature.
• [x] I have created a branch for this patch/feature.
• [x] Each individual commit in the pull request is meaningful.
• [ ] I have added tests to cover my changes.
• [ ] If my change requires a change to the documentation, I have updated it accordingly.

If you're unsure about any of these, don't hesitate to ask. We're here to help!