[Bug] Inability to set BuildOption during pipelines create/update causes pipeline triggers to not fire

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
Azure Cli Version:
Azure-Devops extension version:
```
{
"azure-cli": "2.0.80",
"azure-cli-command-modules-nspkg": "2.0.3",
"azure-cli-core": "2.0.80",
"azure-cli-nspkg": "3.0.4",
"azure-cli-telemetry": "1.0.4",
"extensions": {
"azure-devops": "0.17.0"
}
}
```

Steps to reproduce the behavior:
1. Use PAT to authenticate (I set it as an environment variable `AZURE_DEVOPS_EXT_PAT` per [documentation](https://docs.microsoft.com/en-us/azure/devops/cli/log-in-via-pat?view=azure-devops&tabs=windows#use-environment-variables).
2. Ensure a scenario where an upstream pipeline "a" triggers pipeline "b" by utilizing a pipeline resource with trigger and branch filter in the downstream pipeline. Example:
```
#azure-pipelines-a.yml
jobs:
- job: A
pool:
vmImage: ubuntu-18.04
steps:
- task: Bash@3
displayName: Test
inputs:
targetType: inline
script: |
echo "Running testa"
sleep 10
```
and
```
#azure-pipelines-b.yml
resources:
pipelines:
- pipeline: ci
source: testa
trigger:
branches:
- develop

jobs:
- job: B
pool:
vmImage: ubuntu-18.04
steps:
- task: Bash@3
inputs:
targetType: inline
script: |
echo "Running testb"
```
3. Create both pipelines using `az pipelines create` with org and project arguments, naming the pipelines `testa` and `testb` respectively, choosing `--branch` as develop and referencing appropriate `--yml-path` and repository types.
4. Request [build definition](https://docs.microsoft.com/en-us/rest/api/azure/devops/build/definitions/get?view=azure-devops-rest-4.1) and note that there is no `"options"` data object in the top-level keys of the response shape.
5. Trigger the first pipeline, and validate that there is no consequent run of the downstream pipeline.
6. Go to the first (upstream) pipeline's `Edit -> Triggers (3 dots in right upper corner) -> YAML -> Get sources -> Default` and _re-select_ the default branch that was specified as a command line argument again (i.e., `develop`) and note that, oddly, it allows you to save.
7. Repeat step 4, noting that this time the `defaultBranch` reference has changed from `develop` to `refs/heads/develop`, and that a new section has developed for options:
```
{
"options": [
{
"enabled": false,
"definition": {
"id": "5d58cc01-7c75-450c-be18-a388ddb129ec"
},
"inputs": {
"branchFilters": "[\"+refs/heads/*\"]",
"additionalFields": "{}"
}
},
{
"enabled": false,
"definition": {
"id": "a9db38f9-9fdc-478c-b0f9-464221e58316"
},
"inputs": {
"workItemType": "Bug",
"assignToRequestor": "true",
"additionalFields": "{}"
}
},
{
"enabled": false,
"definition": {
"id": "57578776-4c22-4526-aeb0-86b6da17ee9c"
},
"inputs": {}
}
],
# ...other stuff
```
8. Repeat step 5, and validate that the upstream pipeline is now sending the trigger to the downstream pipeline.

**Expected behavior**
Allow setting of [BuildOptions](https://docs.microsoft.com/en-us/rest/api/azure/devops/build/definitions/get?view=azure-devops-rest-4.1#buildoption), which is what I believe shows up from this manual interation, in order to set definition id `5d58cc01-7c75-450c-be18-a388ddb129ec` and allow for triggers from upstream.

**Additional context**
The changes to the build object are recorded and viewable by diff in `Edit -> Triggers (3 dots in right upper corner) -> History` as well.
Also important to note is that these BuildOptions are not user-specific; `5d58cc01-7c75-450c-be18-a388ddb129ec` actually shows up in this extension's code base as a test case in `tests/recordings/test_build_definition_listShow.yaml`.
Additionally, I left a comment here in a [`vsts-docs` issue](https://github.com/MicrosoftDocs/vsts-docs/issues/6753) to reflect some of the observations here.

Thanks for sitting through my ted talk.