feat: add new constructors

[storopoli]

Description

• Adds new new_* constructors from the different payload types.
• Adds a warning on raw bytes/vec constructors.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

Closes #48.

[AaronFeickert]

Is the use of array references (rather than slices) in the constructors unnecessarily limiting for the caller?

[storopoli]

Is the use of array references (rather than slices) in the constructors unnecessarily limiting for the caller?

I don't think so, because these functions are called with the assumption that the caller knows what the payload is, hence, the array size is known (or should be checked at compile time).
If you don't know what the payload is, then from_bytes/from_vec is the way to go.
That's why we have a "whenever possible" in

bitcoin-bosd/src/descriptor.rs

Line 73 in 99923f6

/// Users are advised to use the `new_*` methods whenever possible.

EDIT: Also taking slices would mean that all these easy constructors (apart from OP_RETURN) would need to return Result<Descriptor, Err>.

[AaronFeickert]

Understood. I was thinking of it more from the caller's perspective, where it would undoubtedly like to avoid an extra copy if it doesn't have the input value as an array already.

[AaronFeickert]

One last nit.

[storopoli]

Gonna leave this until tomorrow so that @bewakes can also take a look if he wants to.

[AaronFeickert]

LGTM. Tests would be a good idea for a future PR as well.

[storopoli]

LGTM. Tests would be a good idea for a future PR as well.

They are in the docstrings with the hidden assert!s

[bewakes]

Could we add tiny unit tests for these? If you think it's too trivial then its fine but it would really be great, for example we might be constructing a different variant than the constructor method intends to.

[bewakes]

They are in the docstrings with the hidden assert!

Oops, just saw this.