Timezone field not required in blueprint

[aerni]

This PR closes #118 and introduces fixes and improvements to how the computed timezone field is handled.

🐛 Bug 1: Unaugmented Raw Value

Problem

If the blueprint doesn't contain a timezone field, but the entry has a timezone value, the computed field would return the raw $value directly. This bypasses augmentation and could lead to unexpected behavior.

Solution

Before returning an existing $value, we now check if the blueprint has a timezone fieldtype that can handle augmentation.

• If it exists, return the $value as-is (it will be properly augmented).
• If it doesn’t, create a timezone field on the fly and return the augmented value.

🐛 Bug 2: Double value() Call

Problem

Calling value() twice causes the raw value to be set to the augmented value, which is unintended behavior.

statamic-events/src/ServiceProvider.php

Lines 101 to 105 in 75741b5

	return $tzField
	->setValue($timezone)
	->augment()
	->value()
	->value();

Solution

Ensure value() is only called once.

✨ Other Improvements

• Creating the timezone field on the fly is now simpler and no longer requires the field to exist in the blueprint.
• This allows developers to remove the timezone field from the blueprint entirely if they don’t want to store the timezone value.
  • In this case, the system will fall back to the default timezone set in the config.
  • Note: Changing the config would retroactively change the timezone for all such entries.
• If consistency is preferred without exposing the field, developers can add visibility: hidden to the blueprint field instead.