Breadcrumbs disabled if _disableToc is true in docfx.json

### Title
Breadcrumbs disabled if _disableToc is true in docfx.json

### Functional impact
I have a project with a very big toc (in the thousands) and the javascript which parses and generates the treeview at the sidebar slows it down. So I would like to disable the treeview either completely, or trim it to show less levels.

But if I disable the sidebar by setting _disableToc = true, the Breadcrumbs get disabled too. If I am disabling the sidebar, the breadcrumbs become the main way to navigate between pages, since you can't select the pages in the treeview.

### Minimal repro steps
Just set _disableToc = true in docfx.json

### Expected result
I would expect to see the sidebar gone, but not the breadcrumbs.
If disableToc is expected to disable all, then it would be nice to have a property to disable only the sidebar like we have _disableBreadcrumb property.

But from what I see here:
https://dotnet.github.io/docfx/tutorial/docfx.exe_user_manual.html

> _disableToc bool Indicate whether to show table of contents on the left of page.

_disableToc is expected to only deactivate the left sidebar.

### Actual result
*What is actually happening?*
The Breadcrumbs get disabled together with the TOC sidebar.

### Further technical details
Looking at the default theme, I can see that the breadcrumbs are generated client-side via javascript in the same code that dynamically loads the TOC treeview. The breadcrumbs are generated in loadToc(); inside docfx.js, and that means that to see the breadcrumbs you need to send all the toc data to the client, which is what I would like to avoid in the first place.

I am not sure on why breadcrumbs are being generated dynamically in the client when it would be simple to generate them statically when building the docs? By being generated statically they would always work (even with javascript disabled) and it wouldn't be necessary to send the whole TOC to the client.

I've made a test here by replacing in breadcrumb.tmpl.partial:
```

• {{_tocTitle}}

```

with
```

{{^breadcumbDef}}

• {{_tocTitle}}

{{/breadcumbDef}}
{{#breadcumbDef}}

• {{name}}

{{/breadcumbDef}}

```
And then defining a breadcrumDef mustache tag in conceptual.html.primary.js with a similar code to the one used today in the client to generate the breadcrumbs.

But while it seems to be working great here I am really no expert on this and I am wondering if there is anything lost by generating the breadcrumbs at build time? I can see many advantages like the ability to disable the sidebar without the breadcrumbs bar, the ability to have breadcrumbs even with js disabled, and the faster loading because we now don't have to run all that js to generate the breadcrumbs in the client. But I imagine there might be drawbacks to generate them on build time, or why was it decided to generate them in the client?