Render `CustomizableOperation` per crate in orchestrator (#2726)

## Motivation and Context
Render `CustomizableOperation` once in the `customizable` module instead
of rendering it in every operation's `builders` module.

## Description
This PR is a follow-up on #2706. The previous PR ported
`CustomizableOperation` in the middleware to the orchestrator but it had
a flaw in that the type was rendered per every operation. This was
clearly a codegen regression because the code for
`CustomizableOperation` is repeated many times and is rendered even if
no customization is requested for an operation.

This PR attempts to fix that problem. Just like `CustomizableOperation`
in the middleware, we render the new `CustomizableOperation` once in the
`customize` module per crate. To accomplish that, the new
`CustomizableOperation` uses a closure, called `customizable_send`, to
encapsulate a call to a fluent builder's `send` method and invokes it
when its own `send` method is called.

~~As a side note, this PR will not take care of the following. We have
[a separate PR](https://github.com/awslabs/smithy-rs/pull/2723

) to fix
them and once we've merged it to this PR, they should be addressed
automatically (there will be merge conflicts, though):~~
- ~~Removing `send_orchestrator_with_plugin` (which is why a type
parameter `R` is present in the code changes, but it'll soon go away)~~
- ~~Incorrect signature of a closure in orchestrator's
`CustomizableOperaton::map_request`~~

## Testing
No new tests added as it's purely refactoring. Confirmed `sra-test`
passed (except for the one that's known to fail).

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._

---------

Co-authored-by: Yuki Saito <awsaito@amazon.com>