Add kiro steering docs

[zoewangg]

Motivation and Context

Add kiro steering docs. I added existing guidelines from docs folder and internal docs. I also added additional guidelines that came to my mind.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[L-Applin]

what about whenComplete? We use it a lot

[L-Applin]

will Kiro know what is "appropriate" or should we elaborate?

[L-Applin]

Does this section seems a bit restrictive? We don't want any other options?

[L-Applin]

SDK ToString utils for toString()?

[alextwoods]

Should we provide guidance to use @nullable instead or just not doing it?

[alextwoods]

Possible additional guideline - do not include fields that could be considered sensitive such as credentials

[alextwoods]

Is this guidance useful for kiro? I think we often use the intelliJ auto-generated implementations, but not sure that will apply well here. I think the guidance maybe should be either: use java.util.Objects helpers or write explicit code.

[RanVaknin]

Should we add a mixed version compatibility guidance?

## Version Compatibility

- **Default Behavior Substitution**: Never replace a conditional code path with an unconditional one without thorough compatibility testing. When a feature flag is removed and a previously optional code path becomes the only path, this constitutes a high-risk change that can break compatibility with older service modules.

- **Method Invocation Pattern Changes**: Be extremely cautious when changing which methods core components call on service interfaces. Even if the interface method exists in older versions, the implementation might throw UnsupportedOperationException or behave differently than expected by newer core components.

- **Interface Default Methods**: When adding methods to shared interfaces that will be called by core components:
  - Implement graceful fallback behavior in core when methods might not be properly implemented when possible.
  - Test with older service versions to verify runtime behavior, not just compile-time compatibility

- **Behavioral Assumptions**: Explicitly document and test assumptions about how service modules implement interface methods. Core components should not make new assumptions about service module behavior without ensuring backward compatibility.

- **Risk Assessment for Code Cleanup**: What appears to be simple "cleanup" or "optimization" can have significant compatibility implications. Always evaluate the runtime behavior changes, not just the code structure changes.

[dagnir]

Doesn't have to be in this PR but I think some guidance around locking and shared resources would be good too. For example w.r.t issues we had around making sure SdkUri/BoundedCache are performant

[dagnir]

Might be good to add an example for this one, it might not be immediately apparent. e.g.

        CountDownLatch latch = new CountDownLatch(1);

        CompletableFuture<URL> future = new CompletableFuture<>();
        
        future.thenRun(url -> {
            downloadUrl(url);
            latch.countDown();
        });
        
        latch.await();

[dagnir]

Another useful method is sometimes we run hundreds/thousands of iterations of a test to ensure that none of the iterations fail, which is helpful for testing race conditions