Update Graduation Checklist links (#3729)

docs/process/graduation.md

@@ -3,8 +3,8 @@ Graduating Components from Experimental
 
 This document contains a checklist for the requirements to migrate a component from experimental.
 
-- [ ] The crate should fully conform with the [ICU4X Style Guide](style_guide.md):
-  - [ ] The crate should have a complete library header as shown in [boilerplate.md](boilerplate.md) with Clippy passing
+- [ ] The crate should fully conform with the [ICU4X Style Guide](https://github.com/unicode-org/icu4x/blob/main/docs/process/style_guide.md):
+  - [ ] The crate should have a complete library header as shown in [boilerplate.md](https://github.com/unicode-org/icu4x/blob/main/docs/process/boilerplate.md) with Clippy passing
   - [ ] The names of exported types should conform to the recommendations in the Style Guide
   - [ ] All Error types should be `Copy`
   - [ ] All constructors should take options structs by value
@@ -25,7 +25,7 @@ This document contains a checklist for the requirements to migrate a component f
   - [ ] There should be a crate-level example that illustrates a common use case for the component
   - [ ] All options and conditional code paths should have a corresponding docs test
 - [ ] The data structs should fully follow ZeroVec style
-  - [ ] Deserialization should not have a "net violation" in the [verify-zero-copy](https://github.com/unicode-org/icu4x/blob/main/provider/datagen/tests/verify-zero-copy.rs) test
+  - [ ] Deserialization should not have a "zero-copy violation" in the [make-testdata](https://github.com/unicode-org/icu4x/blob/main/provider/datagen/tests/make-testdata.rs) test
   - [ ] Constructors should avoid allocating memory in the common case
   - [ ] Opaque blobs of data should be avoided if possible (instead use VarZeroVec, ZeroMap, etc.)
   - [ ] Data structs should not be panicky to load/deserialize and conform to [data_safety.md](https://github.com/unicode-org/icu4x/blob/main/docs/design/data_safety.md)
@@ -36,6 +36,6 @@ This document contains a checklist for the requirements to migrate a component f
   - [ ] The component should be fully covered by FFI with no unjustified suppressions nor entries in missing_apis.txt
 - [ ] The component should encourage i18n best practices
   - [ ] The component should produce correct results in all locales as generated by icu4x-datagen
-  - [ ] Where applicable, the component should be consistent with ECMA-402 and UTS #35
+  - [ ] Where applicable, the component should be consistent with ECMA-402 and UTS#35
   - [ ] Any gaps in i18n quality should be fixed, or, if that is not possible, they should have tracking issues and a concrete, resourced path forward. The intent is to not ship components with known i18n correctness problems and no plan to fix them in an upcoming release
   - [ ] The API design should receive sign-off from a non-ICU4X i18n expert such as Markus Scherer