Support instrumenting components!

[ejrgilbert]

Core Functionality

• Basic round trips
• Get it working again with whamm (currently not reordering everything necessary since I need to flesh out all of the collect phase).
• Flesh out all TODOs in encode logic
• Remove old component encoding logic
• Organize src files
• Add notion of 'scopes' to index spaces (should fix commented out tests in alias.wast, module-link.wast, resources.wast, type-export-restrictions.wast, round_trip_component.rs, and export-introduces-alias.wast), and more...plus -- whamm won't work until I have this either!

Fix workarounds

• Right now, I just assume that CanonicalFunction::Resource* creates a new core function, this isn't necessarily the case. Whether it's a core function or a component function is determined by how it's referenced. The (core func ... (canon resource.drop ...)) is syntax output by the printer to show that a core function is generated for the component function on instantiation and given an ID. I need to figure out how to identify this in my own IR since I need to know IDs at instrumentation time.

Testing

• Add test for performance benchmark
• Add test for memory benchmark

Usability

• Document lookup decisions in comments
  - Also, add the docsrs configuration for enabling all features when it actually runs, so you'll always be able to see documentation for your new feature going forward
  - Use cargo doc --document-private-items to document, code for doing this in docs.rs upon publish:

#+BEGIN_SRC toml
[package.metadata.docs.rs]
rustdoc-args = ["--document-private-items"]
#+END_SRC

• Should I have a fast path for encoding uninstrumented components?
• Should I have a feature flag for encoding instrumented components?
  - A new feature flag may be ideal to ensure no downstream impact
  - Ensure default feature flags (default = [])
  - Hide/optionally include new deps that may be required (your-new-feature = ['dep:some-new-dep', ...])