Introduce `get_option` action

[flixos90]

There has been the option_{$option} filter for a long time, and it makes sense that this filter should be used to tweak options when reading them.

However, there is sometimes a need for running certain logic for when an option is being read. For example, the WordPress performance team is currently working on a feature to optimize the autoloaded options list.

For such purposes, we would like to add a new get_option action:

• The reasoning for making it an action is to not falsely encourage developers to think they could use this to filter an option value (which would be excessive since it would be running for every option read).
• The action would get parameters for the option name, the value, and whether the value is based on the default (rather than being looked up from the database).
• The action name would be aligned with the existing actions add_option, update_option, and delete_option.
• It would be documented so that it should only be used for special cases (similar to e.g. the all filter).

[jorbin]

One alternative idea that could solve this for here and other places in core would be a new suite of functions aallong the lines of:
do_dynamic_action
apply_dynamic_filters
add_dynamic_action

This could work in a backwards compatible way that allows add_dynamic_action( 'option_{$option}', 'callback_on_them_all');. One of the benefits I see is that we wouldn't need to worry about keeping two hooks in sync.

Trac Ticket: Core-56548

## Overview

• This pull request introduces a new action for the get_option function in WordPress to allow developers to run specific logic when an option is being retrieved. The action is designed to facilitate the optimization of autoloaded options while ensuring backward compatibility.

## Changes Made

• Added Action: Introduced a new action named get_option that triggers when an option is read. This action accepts three

• parameters:

• $option: The name of the option being retrieved.

$value: The value of the option.

$is_default: A boolean indicating whether the value is based on the default rather than being retrieved from the database.

### Documentation

Properly documented the new action to clarify its intended use and to guide developers on how to implement custom logic without impacting performance negatively.

## Purpose

The addition of this action allows developers to optimize their use of options without replacing the existing filter mechanism, which is more suited for filtering option values. This change aims to:

• Enhance the performance of retrieving autoloaded options.

• Provide a clear and structured way for developers to hook into option retrieval processes.

• Ensure that developers are not misled into thinking this is a filtering mechanism.

## Compatibility

This new action is fully backward compatible and will not affect existing functionality. It serves as an enhancement for cases where custom logic is necessary when retrieving options.

Hi @mukeshpanchal27 ,
Thanks for letting me know.

The reason I have raised the PR is that the problem statement was straight forward, and if we check on the other functions like add_option, update_option and delete_option, these functions already have the actions implemented, so I generally checked the core's codebase and found that this can be implemented.

Please let me know your thoughts on this. Thanks.

Hi @felixarntz , can you please take a look into this PR. Thanks.