### Apache Airflow version

2.2.0 (latest released)

### Operating System

Ubuntu

### Versions of Apache Airflow Providers

_No response_

### Deployment

Other

### Deployment details

Just used `airflow standalone`

### What happened

First:

TaskGroup does not show the tooltip that is defined for that group on hover
![2021-10-19_17h00_18](https://user-images.githubusercontent.com/35238779/137937706-376922b8-2f79-47ac-9789-6007d135f855.png)

Second:

Providing an Operator with `task_group=` instead of TaskGroup as context manager ignores that TaskGroup's default_args. Using the code I provided below, the task "end" in section_3 has the wrong owner.


### What you expected to happen

First:

If a TaskGroup is used and the tooltip is defined like so:
```python
with TaskGroup("section_1", tooltip="Tasks for section_1") as section_1:
```
the information provided with`tooltip="..."` should show on hover, as shown in the official documentation at https://airflow.apache.org/docs/apache-airflow/stable/concepts/dags.html#taskgroups


Second:

Defining a TaskGroup with default_args like
```python
section_3 = TaskGroup("section_3", tooltip="Tasks for section_2", default_args={"owner": "bug"})
```
should result in those default_args being used by tasks defined like so:
```python
end = DummyOperator(task_id="end", task_group=section_3)
```

### How to reproduce

I have tested this with the below code

```python
from datetime import datetime

from airflow.models.dag import DAG
from airflow.operators.bash import BashOperator
from airflow.operators.dummy import DummyOperator
from airflow.utils.task_group import TaskGroup

with DAG(
    dag_id="task_group_test",
    start_date=datetime(2021, 1, 1),
    catchup=False,
    tags=["example"],
    default_args={"owner": "test"},
) as dag:
    start = DummyOperator(task_id="start")

    with TaskGroup("section_1", tooltip="Tasks for section_1") as section_1:
        task_1 = DummyOperator(task_id="task_1")
        task_2 = BashOperator(task_id="task_2", bash_command="echo 1")
        task_3 = DummyOperator(task_id="task_3")

        task_1 >> [task_2, task_3]

    with TaskGroup(
        "section_2", tooltip="Tasks for section_2", default_args={"owner": "overwrite"}
    ) as section_2:
        task_1 = DummyOperator(task_id="task_1")

    section_3 = TaskGroup("section_3", tooltip="Tasks for section_3", default_args={"owner": "bug"})

    end = DummyOperator(task_id="end", task_group=section_3)

    start >> section_1 >> section_2 >> section_3
```

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

airflow/www/views.py
"""
    Create the list of edges needed to construct the Graph view.
    A special case is made if a TaskGroup is immediately upstream/downstream of another
    TaskGroup or task. Two dummy nodes named upstream_join_id and downstream_join_id are
    created for the TaskGroup. Instead of drawing an edge onto every task in the TaskGroup,
    all edges are directed onto the dummy nodes. This is to cut down the number of edges on
    the graph.
    For example: A DAG with TaskGroups group1 and group2:
        group1: task1, task2, task3
        group2: task4, task5, task6
    group2 is downstream of group1:
        group1 >> group2
    Edges to add (This avoids having to create edges between every task in group1 and group2):
        task1 >> downstream_join_id
        task2 >> downstream_join_id
        task3 >> downstream_join_id
        downstream_join_id >> upstream_join_id
        upstream_join_id >> task4
        upstream_join_id >> task5
        upstream_join_id >> task6
    """
    
    edges_to_add = set()
    
    edges_to_skip = set()
    task_group_map = dag.task_group.get_task_group_dict()
    def collect_edges(task_group):