[Proposal] Provide a way to check if a Grain is already activated without triggering activation

## Background

In many Orleans scenarios, resource efficiency and system performance are critically important. Currently, when you call `GetGrain(id)` and invoke any method on the grain reference, Orleans will automatically activate the grain if it does not already exist. This virtual actor model is powerful for many use cases, but there are practical scenarios where this behavior can be suboptimal:

- **Resource Cost:** Even the minimal creation of a grain instance consumes memory and computational resources on the silo. In high-scale or resource-constrained environments, unnecessary activations can impact overall system efficiency.
- **Business Logic:** Some business workflows require checking whether a grain instance is already live before deciding to proceed (for example, updating configuration or running certain background tasks only if the target grain is already in memory).
- **Avoiding Side Effects:** Triggering grain activation just to check a status or configuration can have undesirable side effects, such as initializing state or running activation hooks unintentionally.

## Feature Request

**Expose an API or mechanism that allows clients (or system components) to check if a grain instance is already activated in the cluster without triggering activation.**

### Possible Approaches
- Public API that queries the Grain Directory or cache for activation existence.
- An option on `GetGrain(id)` or a new API to query activation status.
- Utility methods on `IGrainLocator` or similar interfaces (with proper security/consistency considerations).

## Use Cases
- Efficient background jobs that should only target grains which are already in memory.
- Configuration updates that should only apply to actively running grains.
- System health checks and monitoring tools that need to measure actual active actor counts.

## Why This Matters
- **Resource Optimization:** Saves memory and CPU by avoiding unnecessary activations, especially in large clusters or cloud scenarios with high cost per activation.
- **Performance:** Reduces system churn and increases throughput for scenarios where only active grains matter.
- **Clean Semantics:** Makes it easier to express "only if active" logic directly, rather than working around by adding custom state or making grains self-report their status.

## Additional Context
- Some advanced users currently work around this by maintaining separate indexes or caches, which adds complexity and risk of inconsistency.
- This feature would make Orleans more flexible and suitable for a wider range of high-performance, resource-sensitive scenarios, including IoT, gaming, and SaaS platforms.

**Thank you for considering this proposal!**