Add Sub Categories for Pull Mode Documentation

[Rperry2174]

In #19 I removed a bunch of data that is useful, in favor of making the pull-mode documentation page easier to parse through quickly, find what you need, and have sufficient information to get started.

An example of this is the Profiles Configuration located below. I think we should leave the pull mode page very simple, but add sub-pages that have the following headings moved to their own respective pages:

• Profiles configuration: This is only necessary if you want to scrape other kinds of profiles like goroutines, but we should really double check that this works the way we expect it too and then devote a full page to this if so
• Service Discovery: This is only necessary if you are using Kuberentes so we should move this page to its own sub-page dedicated to using pull mode inside a Kuberentes context

To be added back when this issue is addressed:

### Profiles configuration

> pprof is agnostic to the profile semantics. . . . The interpretation of the reports generated by pprof depends on the semantics defined by the source of the profile
([__pprof authors__](https://github.com/google/pprof/blob/master/doc/README.md#pprof-profiles)).
Pyroscope can pull `pprof` profiles of any type (such as CPU samples, heap allocations, etc) but requires them to be
explicitly described and enabled. Every scrape job explicitly lists which profiles will be pulled in the
`enabled-profiles` parameter. Profiles listed in `enabled-profiles` refer to configurations present in `profiles`.

Default configuration only includes Go `cpu` and `mem` profiles but eventually we will extend the list.
This means that if you want pulling, for example, Go `goroutine` profiles, you will need to explicitly instruct
Pyroscope how to interpret the data:
```yaml
profiles:
  # Profile name that will be referenced from 'enabled-profiles' option.
  goroutines:
    # URL path. Mandatory field.
    path: /debug/pprof/goroutine
    # URL parameters. The value is a string array.
    params:
      seconds: ['10']
    # A profile can include samples of more than one type. For example,
    # Go 'heap' profile includes: inuse_objects, inuse_space, alloc_objects,
    # and alloc_space.
    # Only explicitly listed sample types are retrieved from the profile.
    # At least one sample type should be configured.
    sample-types:
      # Sample type name as specified in the profile.
      goroutines:
        # Fully qualified application name displayed in UI includes sample type:
        # <application_name>.<sample_type>. Optional.
        display-name: goroutines
        # Sample units. Optional.
        units: objects
        # The field specifies how the profile should be aggregated when queried:
        # if the profile represent the current state (for example, memory in use
        # or goroutines dump), 'average' is the most appropriate aggregation.
        # Supported values: average, sum. Defaults to 'sum'.
        aggregation: average
        # If samples represent accumulated value (for example, alloc_space in Go
        # heap profile shows allocated memory in bytes since the program start),
        # the field should be set to 'true'. Defaults to 'false'.
        cumulative: false
        # If values are sampled, the field should be set to true. For example,
        # Go CPU profile: when CPU profiling is enabled, the Go program stops
        # about 100 times per second and records a sample consisting of the
        # program counters on the currently executing goroutine’s stack.
        # If set to 'true', the profile must contain Period duration value.
        # Defaults to 'false'.
        sampled: false

After configuring goroutines profile, it can be added to the enabled-profiles list.

Default profiles configuration:

profiles:
  cpu:
    path: /debug/pprof/profile
    params:
      seconds: ['10']
    sample-types:
      samples:
        display-name: cpu
        units: samples
        sampled: true
  mem:
    path: /debug/pprof/heap
    sample-types:
      inuse_objects:
        units: objects
        aggregation: avg
      inuse_space:
        units: bytes
        aggregation: avg
      alloc_objects:
        units: objects
        cumulative: true
      alloc_space:
        units: bytes
        cumulative: true

I t