feat: support custom writer and storage for apply and preview

[elliotxx]

Purpose:

• Public apply and preview func for external system integration
• Support custom state storage and writer for apply and preview func
• Bump the github.com/pterm/pterm package to the latest version

[coveralls]

Pull Request Test Coverage Report for Build 2507038325

• 20 of 34 (58.82%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.1%) to 75.677%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/kusionctl/cmd/apply/options.go	20	22	90.91%
pkg/engine/states/oss_state.go	0	6	0.0%
pkg/engine/states/s3_state.go	0	6	0.0%

Totals
Change from base Build 2499564529:	-0.1%
Covered Lines:	3690
Relevant Lines:	4876

---

💛 - Coveralls

[healthjyk]

look good to me

[ldxdl]

The interface design of the engine and the options’ pub API is not very reasonable. As here, the runtime interface shouldn't be exposed. @elliotxx and @SparkYuan, pls pay more attention to design and work out a more reasonable API interfaces of option and engine layer. And, we need to reconsider the position and functionality of the option layer, cause each individual layer has its design and cost.

BTW. In general, the interface parameters include three parts, the configurations(str, int, bool..), the feature flags(bools..) and the functional structures(IO, client, etc). The functional structures are injected into the lower layer by the middle layer, and obtained by the factory provided by the lower layer. We can design and implement APIs more standardly.

[elliotxx]

@ldxdl OK, the interface design will continue to be optimized, and we will submit PR separately to solve.
@SparkYuan @howieyuen @markliby We need to optimize the exposed interfaces for the engine and the command line.

[ldxdl]

LGTM