【概要】
幾つかのS2Daoの機能で、
DBFluteとしてはセキュリティホールになってしまうものを
抑制するようにする。

ほとんどのDBFluteユーザはこれらを利用しようとも思わないし、
そもそも知らない人もいるので特に心配はないが、
「S2Daoの経験あります」という人が使ってしまう可能性がある。
（特にSQLアノテーションは）

周辺フレームワークがどうしてもその機能を必要とする場合もある。
例えばBuri、というかDBFlute自身もである。
その場合は、出来る限り方法を変えて実現をする。
無理な場合は、限定的に許容するようにする。

【抑制対象】
A. Queryアノテーション

DBFluteとしてはCBがあるため全く不要な機能であり、
RelKeyで定義されている関連テーブルを全て
取得してしまう欠陥があるため、抑制対象とする。
但し、Buri利用時のgetEntityByIds()は、抑制対象外とする

B. DTOによるSQL自動生成

これもDBFluteとしてはCBがあるため全く不要。
欠陥に関しても「A」と同様なので、抑制対象とする。

C. ARGSアノテーションによるSQL自動生成

これもDBFluteとしてはCBがあるため全く不要。
欠陥に関しても「A」と同様なので、抑制対象とする。
但し、ARGSアノテーション全てを抑制するわけではない、
OutsideSqlで利用するARGSアノテーションはサポートされる。

D. SQLアノテーション

「ちょっとした簡単なSQLはSQLアノテーション」という感じで
利用されることがあるかもしれないが、OutsideSqlTestの対象に
ならずDBFluteの理念からはかなり外れた機能であるため、
抑制対象とする。

E. 外だしSQLでの関連マッピング

「select abc as abc_0」というようにRelnoを付与して、
many-to-oneの関連Entityにマッピングする機能であるが、
DBFluteとしては、Sql2EntityでSQLに対してフラットな
Entity(CustomizeEntity)を提供するやり方をメインとしており、
自動生成の特徴からRelnoがDB変更で変わってしまうため
そもそも「非常に相性が悪い」という点から、今でも
この機能を利用している人はいないと考えられる。
そして、この機能をサポートすることにより、
DomainEntityを利用した場合の外だしSQLのパフォーマンスが
落ちている事実があるため、抑制対象とする。
但し、これはSpecifiedOutsideSql(BehaviorからのOutsideSql)に
限定して対応とする。(内部的な処理の明確化のため)

【利用可能なもの】
今後、Daoインターフェース上で利用可能な機能は以下の二つに絞られる。
o プロシージャアノテーション
o (Daoインターフェース上に定義する)外だしSQL
しかしながら、これらもDBFluteの機能で代替できるため、
基本的には利用することはない機能である。(但し抑制対象にはしない)

【互換性】
Java版においてのみ、SQLアノテーションだけは以下のプロパティを
build-xxx.propertiesに定義することで利用可能になるようにする。

torque.isCompatibleS2DaoSQLAnnotationValid = true

これは以下の２つの理由から：
o SQLアノテーションは他にものに比べて利用されている可能性が高い
o SQLアノテーションは他にものに比べて移行が大変