Fix display and forms for "Fieldable terms"

"a $build_mode param for users would only make sense to force a special, known-to-exist build mode"
Which could be defined by core (currently only 'full') or by contrib. We cannot reason only on what core currently uses.
Since Views can list users, having alternate build modes is precious.

To provide an example I already used in other places, a contrib module that lets admins add custom build modes would be both super easy and super useful (this is also true in D6 land, BTW...)

I'm not sure I get your point, but what i mean is that having user display support build modes has use cases aside from User Display in core (which would be awesome).
I'd even say that, since available build modes are extensible from contrib, 'supporting build modes' is a part of the 'being fieldable' contract, even if the entity itself doesn't actually uses them in its base code.

re moshe #4: "Not at all sure what build modes are needed for terms"
example: list of terms in a side block as a navigational element - I want the term name + description + the picture.
More generally, anything that's 'listable' (Views) has use cases for build modes - of course, you can use 'Field'-style Views for this, but they're harder to theme and reuse, and with Field cache and multiple load, they are not even really faster in simple cases.

But, true, I'm not sure what could be *core* use cases for term build modes. Ni big deal, time will tell :-)

Bumping, + moving this one to taxonomy.module and a twin to user.module

Additionally, it would be really good to move term display to a template.

Let's do this.

This patch is needed anyway to have non-field components ('name' and 'description') display nicely with Field API reorderable fields in 'term edit' forms and on displayed terms.
Bumping back to critical, because reordering fields on terms is broken without this.

A term.tpl.php would be cool, but I don't think it is required to have this patch land.

Turns out we do need a template.
'Term name' behaves exactly like 'node title': when we're on the taxonomy/term/% page for the term, we want the term name out because it's the page title.
OTOH, when people will want to use taxonomy_term_view() in other view modes, they will need the title in.

So attached patch provides a taxonomy-term.tpl.php and template_preprocess_taxonomy_term().
Largely derived and simplified from node.

Screenshot of taxo/term/%tid listing, for a term with a 'multiple' field:
But there's actually no visual difference with HEAD. The difference is in the markup.

Before:

<div class="content"> <!-- The 'Content' region -->
  <div class="field-name-field-multiple">
    ...
  </div>
  <div class="taxonomy-term-description">
    ...
  </div>
  <div id="node-1">
    ...
  </div>
  <div id="node-2">
    ...
  </div>
</div>

After:

<div class="content"> <!-- The 'Content' region -->
  <div class="term-listing-heading">
    <!-- term.tpl.php -->
    <div id="taxonomy-term-1" class="taxonomy_term">
      <div class="content">
        <div class="field-name-field-multiple">
          ...
        </div>
        <div class="taxonomy-term-description">
          ...
        </div>
      </div>
    </div>
    <!-- end of term.tpl.php -->
  </div>
  <div id="node-1">
    ...
  </div>
  <div id="node-2">
    ...
  </div>
</div>

And of course, other difference is that the 'description', which escaped the 'as field' treatment in D7, plays nicely with Field UI d-n-d field reorder.

Patch #13 removed CSS styling for .taxonomy-term-description, but we actually need it when there's no other field in the term (er, which remains the most common case...)

Reroll after #636992: Entity loading needs protection from infinite recursion :
- Moves the recently added entity_prepare_view() call from taxonomy_term_page() menu callback to taxonomy_term_view() API func (just like field_attach_prepare_view())
- Uses the new '__' convention for template suggestions.

I'm away from my usual setup, so no "diff -uP" patch this time. Regular Eclipse-generated patch, no context info. See the patch in #15 if needed, it's the same patch apart from the updates above.

Also, reminder: the patch adds a file (taxonomy-term.tpl.php)

Updated for the remarks in #20.

#678590: Path alias link is below submit button on taxonomy term add has just put back the 'Relations' fieldset and 'URL alias' input in the middle of the form. We'll need to decide what we do with those (reorderable through hook_field_extra_fields(), or just sink at the bottom).

See my comment in #678590-7: Path alias link is below submit button on taxonomy term add.

+ retitle. The scope of the patch is more than $view_mode now.

Bump ?
Patch still applies and works as expected.

Good catch. This didn't show up on a 'taxo/term/%tid' listing page with actual nodes, because the fields in the nodes took care of loading field.css.

Added http://drupal.org/update/modules/6/7#taxonomy_term_view

And sorry for the missing PHPDoc on template_preprocess_taxonomy_term(). Thks Angie.