Extend enable/disable/set-state to all feature view types and REST/gRPC APIs

[rpathade]

Is your feature request related to a problem? Please describe.
The enable/disable/set-state commands for feature view state management (introduced in PR #6401) currently only exist under the feast feature-views CLI group and only support FeatureView and OnDemandFeatureView. There are no REST/gRPC API endpoints for these operations.

Describe the solution you'd like

• Add enable, disable, set-state CLI commands under on-demand-feature-views and stream-feature-views
• Update FeatureStore.enable_feature_view() / disable_feature_view() / set_feature_view_state() to handle StreamFeatureView
• Add REST and gRPC API endpoints for enable, disable, and set-state operations
• Add unit tests for new CLI commands and API endpoints

Additional context
Parent issue: #6331
Follow-up from PR #6401.

[smqd19]

Extending enable/disable/set-state to all feature view types makes sense, especially for consistency. In our own setups, we've often had to do similar updates to keep feature management in sync across different view types. For the CLI additions, consider leveraging Feast's existing command framework — it's flexible enough to add subcommands under new groups like on-demand-feature-views and stream-feature-views.

On the API side, using Feast's current gRPC and REST patterns for feature view operations as templates will help ensure the new endpoints are consistent. If you're using protobufs, adding new request/response messages for these actions should be straightforward. Also, unit tests should mock the FeatureStore methods and API handlers separately, to isolate logic. Combining both CLI and API coverage early can prevent regressions down the line.