Use ActiveModel::Attributes in Aws::Record

### Describe the feature

Rework Aws::Record’s attribute layer so every attribute is registered through ActiveModel::Attributes. Under this approach, string_attr, integer_attr, etc. would become thin wrappers around attribute(name, type, default:), allowing decorators like ActiveModel::Attributes::Normalization#normalizes to hook into Aws::Record models.

Beyond normalization, this change would:

- Enable all current and future ActiveModel decorators (encryption, serialization helpers, etc.) on Aws::Record fields.
- Improve compatibility with form builders and other ActiveModel-based tools because casting, defaults, and dirty tracking come from the canonical Rails implementation.
- Reduce custom infrastructure—bug fixes and improvements in ActiveModel automatically flow to Aws::Record users instead of maintaining a parallel attribute system.
- Provide cleaner extension points: developers can register custom ActiveModel::Types or third-party decorators without fighting the DynamoDB marshaler layer.
- Simplify the codebase by letting ActiveModel::AttributeSet/ActiveModel::Dirty handle state tracking, trimming down ModelAttributes and ItemData.

### Use Case

We attempted to use the [new normalizes macro](https://github.com/rails/rails/discussions/53793) in our case for email addresses in an Aws::Record-backed app:

```ruby
class Contact
include ActiveModel::Model
include ActiveModel::Attributes
include Aws::Record
include ActiveModel::Attributes::Normalization

string_attr :email
normalizes :email, with: -> value { value&.strip&.downcase }
end
```

That doesnt work.

Because every persisted field in BaseModel is declared with the Aws::Record macros (string_attr, integer_attr, etc.), the ActiveModel decorator hooks never see read/write operations, so normalization callbacks don’t fire. To make normalizes effective we’d have to redefine every attribute twice (attribute :foo for ActiveModel, plus string_attr :foo for Aws::Record) or build a bridge layer that makes Aws::Record emit the decorators ActiveModel expects. Both approaches would be fragile and risk the DynamoDB mapping getting out of sync. In short: adding include ActiveModel::Attributes to BaseModel won’t crash immediately, but it also doesn’t give us working normalization for the attributes we actually persist.

So we must maintain custom concerns instead of relying on the Rails-provided API.

### Proposed Solution

Integrate ActiveModel::Attributes into Aws::Record’s core:

1. Mix ActiveModel::Attributes into Aws::Record.
2. Update attribute macros to call attribute(name, type, default:), wrapping existing DynamoDB marshalers in ActiveModel::Type subclasses.
3. Preserve Dynamo-specific metadata (hash/range keys, GSIs, custom storage names) in side tables so persistence logic remains intact.
4. Allow decorate_attributes to run on every field, unlocking normalization and other decorators.
5. Refactor ModelAttributes/ItemData to lean on ActiveModel::AttributeSet and ActiveModel::Dirty for defaults and mutation tracking.

Prototype sketch:

```ruby
class DynamoStringType < ActiveModel::Type::String
def serialize(value)
Aws::Record::Marshalers::StringMarshaler.new.serialize(value)
end
end

def string_attr(name, default: nil, **opts)
register_dynamo_metadata(name, opts)
attribute(name, DynamoStringType.new, default: default)
end
```

### Other Information

_No response_

### Acknowledgements

- [ ] I may be able to implement this feature request
- [x] This feature might incur a breaking change

### aws-sdk-ruby-record version used

latest

### Environment details (OS name and version, etc.)

mac