refactor!: rename boolean variables to follow Dart naming guidelines

[DCodeProg]

Description

This PR refactors boolean variable names across the codebase to align with Dart Design Guidelines.

The refactoring applies different conventions based on context:

• Properties: Use verb phrases (isEnabled, hasElements, canClose)
• Named Parameters: Omit the verb when it improves readability (disabled: true, ephemeral: false)
• Setter Methods: Use simple parameter names like value when context is clear

Key Changes

Boolean Naming Consistency

• Renamed boolean properties across many classes to use "is" or "has" prefixes for clarity (e.g., animated → isAnimated, inline → isInline, disabled → isDisabled, nsfw → isNsfw, authorIsBot → isAuthorBot, managed → isManaged, available → isAvailable). [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]

Command and Option Parameter Updates

• Updated constructors and factory methods for command options and choice options to accept the new isRequired parameter instead of required, and updated all usages accordingly. [1] [2] [3] [4]

Component and Embed Field Updates

• Changed component and embed field classes (e.g., Button, SelectMenu, Separator, MessageEmbedField) to use the new boolean property names, and updated their serialization logic to match. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

Activity, Channel, Emoji, and Message Model Updates

• Applied the new naming convention to properties in activity, channel, emoji, and message models, including their constructors and JSON serialization/deserialization. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

These changes improve code readability and maintainability by making boolean property intent explicit and consistent across the codebase.

Benefits

• Consistency: Clear distinction between properties (with verbs) and named parameters (without verbs)
• Readability: Named parameters read more naturally (disabled: true vs isDisabled: true)
• Clarity: Setter methods use value when the method name provides full context
• Standardization: Adheres to official Dart effective style guidelines

Breaking Changes

This is a breaking change as it renames public fields and named parameters in constructors and methods. Developers will need to update their code to use the new parameter names.

Related Issue

Closes #318

Type of Change

• feat
• fix
• docs
• refactor
• chore
• test

Checklist

• I have followed the Conventional Commits naming rules
• All existing tests pass