Monorepo support for OpenCLI plugin installation and discovery

# Support monorepo-friendly plugin installation and discovery

## Summary

OpenCLI plugin installation and discovery currently work best when each plugin lives in its own standalone repository and is installed into a flat directory under `~/.opencli/plugins//`.

This works well for simple community plugins, but it becomes limiting for teams that want to maintain multiple related plugins in a single monorepo.

## Current behavior

From the current implementation and docs:

- `opencli plugin install` only supports:
- `github:user/repo`
- `github.com/user/repo`
- Installed plugins are expected to live in:
- `~/.opencli/plugins//`
- Plugin discovery treats each subdirectory under `~/.opencli/plugins/` as one plugin
- Files are scanned flat inside that plugin directory
- Nested plugin directories are not discovered

This means a monorepo like:

```text
automation-plugins/
packages/
opencli-plugin-team/
opencli-plugin-kim/
```

cannot be used directly with the current install/discovery model.

## Why this matters

For internal automation teams, monorepos are often the most practical way to manage multiple OpenCLI plugins because they allow:

- shared helpers and runtime utilities
- shared docs and setup scripts
- consistent linting / testing / release flow
- cross-plugin workflows, for example one plugin reading data from one system and another plugin writing to another system

Without monorepo support, users need to:

- keep one repo per plugin,...